Discussion :

[igorzup]

perso, je vois plus l'utilisation du mdp comme un moyen de se decharger de la securité.

souvent les utilisateurs ont des mdp simples genre le nom du toutou sans chiffre.

dans un reseau d'entreprise, la sécurité est gérée en amont et pas au niveau de l'utilisateur.

donc un moyen d'authentif recupéré de l'AD ou un stockage (a la thunderbird/firefox) me semble plus réalistes.

me plante je?

En plus c'est quand meme booooooocoup plus simple et propre de gerer la securité des appli sur l'AD pour un admin...

me replante je?

[Invité]

Tu entends quoi par gérer la sécurité en amont dans AD ? Explique la méthode, que fait l'utilisateur pour s'authentifier ? Comment sais tu que tu as à faire à la bonne personne ?

[g0up1l]

Une solution est d'implémenter un serveur de licences.

1 - ton appli se connecte à un service web qui lui demande un code
2 - si le code est OK ton appli à le droit de fonctionner

Dans ce cas, toute ta sécurité est sur ton serveur web, donc pas 'directement' soumis aux attaques de force brute

[Invité]

Oui mais le code est où ? en dur ?
Et n'importe qui peut lancer l'appli est accéder à la base de donnée, car l'appli s'identifie mais identifie pas si la personne qui l'a lancée à vraiement le droit de le faire...

[igorzup]

@george7
faut pas tout melanger.
gerer la securité en amont c'est une chose et s'enregistrer dans l'AD une autre.

l'AD te donne l'acces a l'appli en fonction de ton login c'est tout (tout comme l'acces SQL)

la sécurité est gérée en amont, c'est a dire par ton reseau...
s'il y en a une... c'est vrai.

@g0up1l (c'est ton mdp au passage? ... juste pour rire!)
on s'est compris sur le fond d'une authentification/acces decentralisée

maintenant, ca m'a l'air compliqué de mettre ca en oeuvre en java...
du coup une sorte de clef crypté en fichier m'a traversé l'espit...

je reviens a ma question de depart:
sans intervention de l'utilisateur, comment vous vous y prendriez au plus simple?

[Invité]

Je ne mélangeais pas, je suis juste intéressé... Parce que là tu te bases sur le fait que la personne enregistrée peut accéder aux données, c'est bien mais le problème de mot de passe que tu as soulevé intervient ici : si la personne a un mot de passe genre son nom ? Ou si l'utilisateur laisse sa session ouverte ?
Moi je te le dis : sans intervention de l'utilisateur je ne ferais rien car, si tout est écrit en dur, la sécurité est plus que relative à mon sens, voire inexistante, donc pourquoi se casser le crâne ? (je schématise un peu mais quand même)
Ceci dit ensuite ce n'est que mon avis
Mettre ta clef dans un fichier c'est ok, mais ensuite il est très facile de la lire, il suffit d'ouvrir le fichier. Si tu veux protéger ta clef, il t'en faudra une autre, comme il a été dit plus haut, on se mord la queue

[igorzup]

chui dac

laisser sa cession ouverte et avoir un mot de passe blanc c'est kifkif...

Si l'utilisateur s'est fait voler sa cession, pour moi il y a fraude et il y a intention réelle de voler des infos.
a partir de la, si le mot de passe ppal a ete outrepassé, c'est deja que le "pirate" avais du temps et un minimum de connaissances...

pour moi une bonne visu offerte aux utilisateur sur les dernières taches effectuées sous leur profil suffit a les alerter.

et en tout cas, perso, je suis pas favorable a surcharger les couches de securité qui au final font perdre beacoup de temps a tout le monde et apportent toujours une securité tres relative surtout face a un vrai pirate.

le login ouinedoze me suffit et je prefere me baser dessus.
mais une restriction/gestion des acces et de bon logs sont essentiels

[g0up1l]

Oui mais le code est où ? en dur ?
Et n'importe qui peut lancer l'appli est accéder à la base de donnée, car l'appli s'identifie mais identifie pas si la personne qui l'a lancée à vraiement le droit de le faire...

Le mot de passe, c'est l'utilisateur qui doit le fournir à chaque ouverture de l'appli. Comme pour une messagerie OutLook d'entreprise par exemple.
A partir de là, si l'utilisateur choisit de faire enregistrer son mot de passe en local pour que l'appli se souvienne de lui, il doit être conscient qu'il baisse le niveau de sécurité.Tout comme quand il s'absente en laissant la session ouverte...
De toutes façon, le maillon faible de la sécurité, c'est l'utilisateur.

[Invité]

Le mot de passe, c'est l'utilisateur qui doit le fournir à chaque ouverture de l'appli. Comme pour une messagerie OutLook d'entreprise par exemple.
A partir de là, si l'utilisateur choisit de faire enregistrer son mot de passe en local pour que l'appli se souvienne de lui, il doit être conscient qu'il baisse le niveau de sécurité.Tout comme quand il s'absente en laissant la session ouverte...
De toutes façon, le maillon faible de la sécurité, c'est l'utilisateur.

Voilà mais igorzup ne veut pas de mot de passe, spour ca qu'il y a toute cette discussion
Sinon je suis d'accord avec toi

[igorzup]

moi aussi

[igorzup]

cette discution est elle morte?

personne ne vois de moyen quel qu'il soit de securiser un minimum et de facon simple sans mettre de mdp utilisateur?

[fr1man]

Tu as eu pas mal de réponses non ?

[igorzup]

bah j'ai un arrière gout de "qui-c'est-qu'a-pas-dit?"

mais je regarde du coté JCIFs (avec plus tard certainement un question ou deux a tchize)
[mode peteplomb on]
blagounette : tchize beau regard!
désolé
[mode peteplomb off]

mais je cogite a ca, j'ai quelques idée simple et pas trop conne je pense!

allez, sans autre reponse je clos

[edit:] j'etait po bien moi ce matin! désolé tchize t'est victime de mon fanatisme de "mon nom est personne"