Discussion :

[Frankywinky]

Bonjour,

Il serait bien pratique d'inclure, dans mes applications Java, un bouton "Mémoriser mon mot de passe", pour que les usagers ne soient pas obligés d'entrer leurs noms d'utilisateur et mots de passes SQL à chaque utilisation de l'application. Je cherche cependant une façon sécure de mémoriser les mots de passe (et si j'utilise une méthode d'encryption, je dois aussi pouvoir décrypter l'information).

Je pourrais chercher une façon simple d'encrypter l'information dans un fichier, mais j'ai peur que ce ne soit pas sécuritaire (et les classes java se décompiles trop facilement).

Il existe, sur la plupars des OS, des systèmes pour mémoriser les mots de passe (comme le "Trousseau d'accès" sur Mac OS X). Y a-t-il un moyen en Java de faire appel à un tel programme, et ce, indépendamment de la plateforme (mes applications peuvent rouler sous Mac OS X, Windows et, moins fréquemment, sous Linux).


Merci de votre aide,


François

[afrikha]

Une idée qui me passe par la tête :
Encapsuler le mot de passe dans un objet que tu "sérialise" dans un fichier, non ?

[le y@m's]

Une idée qui me passe par la tête :
Encapsuler le mot de passe dans un objet que tu "sérialise" dans un fichier, non ?

Attention, la sérialisation d'un objet est très loin de "masquer" les attributs d'un objet. Essaye avec un objet d'une classe contenant un simple attribut de type String, sérialise le dans un fichier puis ouvre celui-ci dans un éditeur de texte. Tu verras alors que la chaine de caractères reste "visible".

[Frankywinky]

Et justement, je cherche une façon véritablement sécuritaire. J'espèrais ne pas en arriver à une solution maison, car il est trop facile de décompiler l'algorithme de décryption (ou de faire appel a une de mes fonctions à partir d'une autre classe).

Le problème embêtant, c'est que je partage le logiciel disponible sur notre réseau d'entreprise pour les usagers qui en ont besoin. Alors, pour éviter le piratage, il serait mieux d'utiliser quelque chose de plus fiable pour mémoriser le mot de passe. Si je n'ai pas une solution convenable, je ne permettrai simplement pas la mémorisation du mot de passe. (Ah l'administration système ! )

Mais enfin, merci pour la suggestion

D'autres idées ?

[le y@m's]

Regarde du coté du package javax.crypto, apparement les fluxs CipherInputStream/CipherOutputStream semble être une piste intéressante.
Malheureusement je ne connais pas très bien JCE et ne te serais donc pas d'une grande aide là dessus.
Donc avis aux connaisseurs de JCE, en attendant voici un peu de lecture : Java Cryptography Architecture API Specification and Reference.

[afrikha]

Attention, la sérialisation d'un objet est très loin de "masquer" les attributs d'un objet. Essaye avec un objet d'une classe contenant un simple attribut de type String, sérialise le dans un fichier puis ouvre celui-ci dans un éditeur de texte. Tu verras alors que la chaine de caractères reste "visible".

Effectivement c'était une mauvaise idée ...
Une autre raison est que l'objet sérialisé pourrait étre désérialisé à partir d'une autre application java, et après un bon coup de réflection et le tour est joué.
Bref, c'est une très mauvaise idée

[benratti]

Regarde du coté de SSO, mais c'est pas evident à mettre en place... je te le dit juste pour information.

[joseph_p]

De manière plus globale, tu peux aussi offusquer ton code pour le rendre moins lisible à ceux qui le décompilerait.

Pour ce qui est du mot de passe en lui même et de le stocker au niveau de l'interface utilisateur, rien ne t'empêche non plus de lui appliquer un cryptage (MD5 par exemple). C'est d'ailleurs la solution propre en web pour passer des mots de passe entre client et serveur, bref c'est pas si mal.

[thibaut]

Je ne suis pas certain que MD5 ne soit pas déchiffrable... Moi je recommanderai DES ou SHA pour être certain que le mot ne passe ne soit pas décryptable.

[sinok]

aucun algo de cryto n'est incassable, mais md5 ou sha nécessitent de passer en force brute (de toute façon c'est du hachage et non du crytage pour ces deux là, l'opération est irréversible)

[joseph_p]

Sinok, fort belle explication : lorsque j'ai écris mon poste je savais que cryptage n'était pas approprié mais je ne savais plus le mot qu'il fallait mettre lol

Ceci dit, je vois guère comment mieux protéger qu'une clé de hashage le mot de passe en tant que tel. En effet, il n'y a pas moyen d'intercepter les communication entre la fenêtre et le code il me semble (contrairement à du web), du coup ça limite déjà une bonne partie des risques.

Ensuite, il me semble qu'on peut très bien accéder au dossier personnel de la personne et y déposer là le bébé, avec les droits correspondant à la personne. Là encore ça renforce la sécurité.

Après, pour un maximum de sécurité, on doit pouvoir concevoir des algo avec des clés publiques/externes pour complexifier encore la démarche, mais cela requiert un effort supplémentaire et/ou un accès web.

Bref, le mot de passe haché puis stocké dans un fichier dans le répertoire de l'utilisateur me paraît déjà pas mal. Quelqu'un voit plus ?

[sinok]

Le grain de sel pour le hachage

[had35]

Pour parler d'une manière générale, comme dit sinok il n'a aucun moyen d'échapper au jeu du chat et de la souris. Et la souris, c'est celui qui cherche à protéger ses données Bref, il faut être en perpétuel mouvement.

Bien sûr, les efforts à fournir doivent être en rapport avec le degré de confidentialité recherché. Pour des données vraiment sensibles, il n'est pas sérieux de faire reposer la politique de confidentialité sur la robustesse du système hôte (sans faire de MS bashing). Le problème lorsqu'une info est cryptée dans un fichier est que, une fois l'accès au fichier dévérouillé, il peut être accédé sans limite, hors les processeurs aujourd'hui sont devenus diablement puissants ...

Quant au stockage distant, sa faiblesse repose sur la fiabilité du protocole de communication.

[Frankywinky]

Merci tout le monde pour vos réponses.

En effet, je ne peux pas utiliser un procédé indécryptable, étant donné que le mot de passe doit être passé intacte à un DriverManager.getConnection(...), alors j'ai besoin de décrypter.

La seule solution, si je veux enregistrer le mot de passe dans un fichier, c'est de faire comme suggère ZedroS, mettre les permissions sur le fichier dans lequel j'écris le mot de passe, cependant je ne suis pas à l'abris des modifications aux permissions que peut faire l'utilisateur, mais tant pis!

Et si quelqu'un en arrivait à faire quelque chose au point de ce que had35 nous parle, je sens que cette personne aurait mieux à faire que de s'intéresser aux mots de passe de simples usagers... gloups.

Quant à SSO, je ne pense pas vraiment pouvoir utiliser cela pour le DriverManager.

J'aurais quand même aimé utiliser une application indépendente pour se souvenir des mots de passe. Je veux dire, s'il avait existé une façon uniforme dans chaque système d'exploitation que de se souvenir des mots de passes des applications, ça aurait été pratique. Je constate que chaque application a plus ou moins sa façon de sauvegarder les mots de passe.

Peut-être que je pourrais faire du code natif pour utiliser le trousseau d'accès sous Mac OS X, et kdewallet sous KDE, etc. Mais ça commence à faire pas mal de travail...

[joseph_p]

Par contre, Frankywinky, je te conseille fortement de n'utiliser que le mot de passe haché dans toute ton application, c'est bien mieux que de stocker quelque part et/ou transmettre un mot de passe en clair (dans la mesure où tu en as la possibilité) !

D'ailleurs, ton getConnection(), c'est pour faire du JDBC ?

[had35]

Et si quelqu'un en arrivait à faire quelque chose au point de ce que had35 nous parle, je sens que cette personne aurait mieux à faire que de s'intéresser aux mots de passe de simples usagers... gloups.

Je ne propose rien de particulier Je dis simplement que le cryptage d'un mot de passe dans un fichier, c'est uniquement pour se rassurer.
En revanche, ce que je n'ai pas clairement évoqué, c'est qu'il est possible d'authentifier une connexion sans avoir besoin de demander un mot de passe. Mais bon, je ne sais pas s'il existe des api toutes faites pour mettre ça en application.

[EDIT] http://jsdsi.sourceforge.net/

[Frankywinky]

En effet, ZedroS, getConnection c'est pour JDBC. Mais je compte aussi utiliser la même méthode pour télécharger une page web à partir d'un intranet avec HttpURLConnection (considérant que le USER/PASS est le même que la connexion JDBC).

had35, puisque les usagers utilisent déjà des applications pour mémoriser leurs mots de passe dans d'autres applications, je pense que le mal est déjà fait. Mais par contre, je m'interrogeais sur le fait qu'il était peut-être possible d'avoir quelque chose d'au moins aussi sécuritaire que les applications déjà utilisés pour sauvegarder les mots de passe.

[had35]

Mais par contre, je m'interrogeais sur le fait qu'il était peut-être possible d'avoir quelque chose d'au moins aussi sécuritaire que les applications déjà utilisés pour sauvegarder les mots de passe.

La seule solution pour crypter un mot de passe de façon sûre, j'ai l'air d'être un peu sûr de moi là , c'est de le crypter avec un autre mot de passe ...

Ou alors de bidouiller un truc maison en faisant reposer la sûreté sur le secret de l'algorithme.

Sur des plateformes robustes, il serait bien possible de compter sur la restriction des droits, mais toutes ne le sont pas.

[benratti]

Ou alors de bidouiller un truc maison en faisant reposer la sûreté sur le secret de l'algorithme.

L'histoire de la cryptographie montre qu'il ne faut pas utiliser cette methode. D'ailleurs, une des bases de la cryptographiqe moderne est que le secret ne doit pas resider dans l'algorithme mais dans une clé. Cela pour une raison toute simple... si ton algo est decouvert, il faut que tu changes d'algo, si ta clé est découverte, tu dois juste chngé de clé. je te laisse deviner lequel est le plus couteux.

[Frankywinky]

Je crois que finalement, il n'y a rien de mieux que de ne pas sauvegarder le mot de passe (je peux quand même sauvegarder le nom d'usager). À moins que quelqu'un d'autre propose quelque chose de mieux ?

Sinon, je n'ai qu'à attendre l'encryption quantique