Discussion :

[hansaplast]

voila, suite a un topic que j'ai lut dans la section java : "cryptage de mot de passe en local"
je me demandait :

ne serait t il pas possible, a partir d'un mot de passe, de générer une table de hachage, non pas hexadecimale, et d'un tel nombre de bit. Mais plutot, au format date?

je m'explique : la plupart des algos de rand que j'ai vu, se base sur l'heure courante (en millisecondes) pour générer une serie de nombres la plus aléatoire possible entre deux tentatives.

dinc, si on arrive a générer une date, en milliseconde, unique par mot de pass, et qu'a chaque rand, on fasse un saut toujours identique, il serait alors possible de générer autant de fois que voulut la meme clef de cryptage, et, alors, on n'aurait plus besoin de stocker les clefs en local (le pb du topic cité plus haut)

voila, c'est plus que ca me titillait l'esprit qu'autre chose...

[jobherzt]

je ne comprend pas trop ce que tu veux dire... si tu garde en memoire la date de creation du mot de passe pour t'en servir pour generer une cle, alors il suffit de connaitre cette date (stockée en claire) pour deviner la clée... pas tres secure !!

accessoirement, la generation de nombre (pseudo)-aleatoire en se basant sur le nombre de milliseconde en cours n'est absolument pas cryptographiquement sûr.. la generation de nombre aleatoire est un probleme complexe, et c'est souvent une faille privilégiée dans l'implementation d'un algo de cryptage (car négligé.. )

[hansaplast]

en fait, je ne suggere pas de garder la date de création du password, mais d'utiliser le password lui meme pour générer un format date :

a 'linstar du MD5, l'empreinte numérique du hash ne serait pas une séquence hexadécimale, mais un format date (i.e. : 16/06/1432:14h36mn1250ms)

ensuite, soit, ton pas est généré a partir du mot de passe (i.e. : pas de 14ms) soit constant.


a partir de là, il serait peut etre possible de générer un serie pseudo aléatoire de nombres, et surtout, fixe, pour un mot de passe donné, non?

[jobherzt]

la question est : pourquoi s'embeter a passer par un format date ? pourquoi ne pas utiliser directement un hash "normal" qui est beaucoup plus "chargé d'aleatoire" ?

l'autre question est : pourquoi regenere la cle a chaque fois, alors qu'on peut la crypter en utilisant le mot de passe ?

ou alors, je ne vois pas ou tu veux en venir...

[hansaplast]

la question est : pourquoi s'embeter a passer par un format date ? pourquoi ne pas utiliser directement un hash "normal" qui est beaucoup plus "chargé d'aleatoire" ?

bein...
oups, autant pour moi :'(

l'autre question est : pourquoi regenere la cle a chaque fois, alors qu'on peut la crypter en utilisant le mot de passe ?

ou alors, je ne vois pas ou tu veux en venir...

en fait, c'est en reference au topic suivant :
http://www.developpez.net/forums/sho...d.php?t=187443

la personne en question cherchait une solution de stockage de clef sûre, en local. Son point de depart etant : le stockage dans un fichier n'est pas securisée.

mon idée est donc de ne rien stocker, et de trouver une methode permettant de regenerer une clef identique, a partir d'une entrée (le mot de passe). Et que, si l'entrée (le mot de passe) est differente, la clef, soit elle aussi differente.

avant de lui suggérer, j'ai voulut m'assurer de la non-debilitée de mon idée, etant donné que, je ne suis pas géo trouvetout... elle aurait du lui etre suggérée si elle etait faisable.

[Drizzt [Drone38]]

Et puis meme si tu ne stockes pas la clef, tu dois stocker le mdp.
Et comme tu as une bijection entre ton mdp et tes clefs, tu n'ajoutes aucune sécurité.

Moralité tu te retrouves au point de départ

[jobherzt]

oui, j'ai lu son post, c'etait pas tres clair.. en gros, il veut que son programme soit capable tout seul comme un grand, de decrypter un mot de passe stocké en local... mais quelque soit les solutions proposée, open source ou pas, je pense que c'est impossible a faire sans ouvrir une enorme breche.

la question est : pourquoi veut il recuperer ce mot de passe ? vu que l'utilisateur va le taper, ne serait ca pas plus simple de verifier qu'il est bon, puis de le recuperer a partir de ca qu'a tapé l'utilisateur ?

[hansaplast]

en gros, la soolution tordue que je voulait lui proposer est celle là :

l'utilisateur saisi un mot de passe.

a l'aide du mot de passe et d'un algo de hash, le mot de passe est crypté en fonction d'un clef qui lui est propre.


lorsque l'utilisateur se re-connecte au programme, on lui redemande le mot depasse, a l'aide de celui ci, on regénere les memes clef, on decrypte l'ancien (ou re-encypte le nouveau) puis, on compare les resultats.

une autre solution serait 2 mots de passe :
celui a stocker, et celui servant a générer les clefs.

(celui générant les clef serait générique, et pourrait servir a stocker X mots de passe)

j'ai l'impression depas etre clair... =>

Et puis meme si tu ne stockes pas la clef, tu dois stocker le mdp.
Et comme tu as une bijection entre ton mdp et tes clefs, tu n'ajoutes aucune sécurité.

le but est, justement de stocker du crypté, d'ou une génération

• constante pour un mot de passe fixe
• differente pour chaque mot de passe different

quand au post java :

la question est : pourquoi veut il recuperer ce mot de passe ?

je pense que ce qu'il veut, c'est créer une appli qui stocke tous ses mots de passe pour lui. La "solution" que je soumet a votre aval, serait non pas que l'appli stock tous les mots de passe, mais qu'elle en stock n-1 : le seul a connaitre serait celui servant a l'encryption.

[jobherzt]

donc pour faire simple, le mot de passe est crypté avec lui meme comme clé. ca se fait, mais ca ne repond pas vraiment a mon objection : s'il veut avoirle mot de passe en clair a un moment donné pour une raison X ou Y, pourquoi ne pas prendre ce qu'as tapé l'utilisateur ? parce que de 2 choses l'une :

- soit il faut connaitre le mot de passe pour le decrypter, et dans ce cas je ne vois pas l'interet (cf objection)
- soit le but est de pouvoir acceder au mot de passe sans que l'utilisateur ne l'ai tapé, et dans ce cas d'ne maniere ou d'une autre il ya un probleme.

en fait, je crois qu'il faut vraiment se demander ce qu'il veut faire : je traine pas mal sur un forum de php, et je vois souvent qui essaient de trouver des slutions miracles de ce genre pour augmenter la securité, ou qui veulent pouvoir par exemple restituer le mot de passe a quelqu'un qui l'a oublié, c'est generalement des remedes pires que le mal.. je crains qu'on soit aussi dans un cas de ce genre !

son probleme particulier s'inscrit dans une strategie plus globale, la question a se poser est : "est il necessaire qu'il en vienne a resoudre ce probleme, ou existe t il une meilleure strategie qui lui evite d'en passer par cette situation insoluble ?"

[hansaplast]

donc pour faire simple, le mot de passe est crypté avec lui meme comme clé. ca se fait, mais ca ne repond pas vraiment a mon objection : s'il veut avoirle mot de passe en clair a un moment donné pour une raison X ou Y, pourquoi ne pas prendre ce qu'as tapé l'utilisateur ? parce que de 2 choses l'une :

- soit il faut connaitre le mot de passe pour le decrypter, et dans ce cas je ne vois pas l'interet (cf objection)
- soit le but est de pouvoir acceder au mot de passe sans que l'utilisateur ne l'ai tapé, et dans ce cas d'ne maniere ou d'une autre il ya un probleme.

pas vraiment, puis-que, pour X mots de passes (par exemple 15), il suffit d'en avoir 1 qui permet de les decrypter tous

en fait, je crois qu'il faut vraiment se demander ce qu'il veut faire : je traine pas mal sur un forum de php, et je vois souvent qui essaient de trouver des slutions miracles de ce genre pour augmenter la securité, ou qui veulent pouvoir par exemple restituer le mot de passe a quelqu'un qui l'a oublié, c'est generalement des remedes pires que le mal.. je crains qu'on soit aussi dans un cas de ce genre !

son probleme particulier s'inscrit dans une strategie plus globale, la question a se poser est : "est il necessaire qu'il en vienne a resoudre ce probleme, ou existe t il une meilleure strategie qui lui evite d'en passer par cette situation insoluble ?"

là, tu a raison


mais, son probleme peut etre vu comme un pretexte aux propos que je tient :
lorsque j'ai lut sa question, ca en a elevé une autre en moi, n'ayant pas le temps de n'implementer, et surtout, pas la connaissance en securitée nescessaier pour evaluer sa faisabilitée, je m'en suis remis a vous


en fait, mon interrerogation portait plus sur la viabilitée de l'ago que je proposait (générer une paire de clef a partir d'un MDP) que sur l'application possible pour le cas particulier evoqué plus haut


cependant, la finalitée de ma proposition n'etant pas connue, et l'interet d'en trouver une surement plus que limité, je met le topic en resolut.

ps : je lui met ce topic en lien, dans le sien, afin qu'il puisse s'informer de vos commentaire, qui pourraient lui servirent

[jobherzt]

ok, ca par contre, generer une paire de cle a partir dun mot de passe ca peut se faire..

en fait, en general on le fait quand on est dans le cas d'un cryptage symetrique : le plus simple, c'est de hasher le mot de passe pour obtenir la longuer de cle standard, puis de se servir du has comme cle. il faut evidemment que le hash ne soit pas stocké par ailleurs !! donc il faut un MDP specifique au cryptage

pour les cles publiques, privées, comme il faut des propriétés specials (nombres premiers), on genere une cle au hasard et on la crypte symetriquement avec le mot de passe.

se servir du mot de passe pour initialiser le generateur aleatoire, pourquoi pas.. mais la generation d'une cle assymetrique est tres long, donc ca n'est pas tres interressant de la regerener a chaque fois.

[®om]

la question est : pourquoi veut il recuperer ce mot de passe ? vu que l'utilisateur va le taper, ne serait ca pas plus simple de verifier qu'il est bon, puis de le recuperer a partir de ca qu'a tapé l'utilisateur ?

Salut,

(c'est moi qui ai posé la question sur l'autre post)

Ce que je voulais faire (ou plutôt savoir faire, vu que c'est simplement une question que je me pose, je n'en ai pas besoin dans l'immédiat), c'est faire un peu comme sur firefox, tu tapes ton mot de passe une fois pour toutes, et il est mémorisé pour les fois suivantes.

Cela permettrait par exemple pour un programme en java d'aller se logger sur un forum pour récupérer des infos en parsant, et lors d'un futur lancement de l'appli java, pouvoir s'y reconnecter sans avoir à redonner le mot de passe...

[jobherzt]

je crois que ce que fait firefox n'est pas forcement tres securisé.. je ne me suis jamais posé la question, mais a priori ils sont stockés en clair... on peut considerer que ca n'est pas trop dangereux tant que :

- tu es le seul a acceder a l'ordi ( ou alors ce ne sont que despersonnes de confiances)
- ca ne touche pas a des données trop confidentielle.

[®om]

je crois que ce que fait firefox n'est pas forcement tres securisé.. je ne me suis jamais posé la question, mais a priori ils sont stockés en clair... on peut considerer que ca n'est pas trop dangereux tant que :

- tu es le seul a acceder a l'ordi ( ou alors ce ne sont que despersonnes de confiances)
- ca ne touche pas a des données trop confidentielle.

Oui mais firefox accepte des plug-ins, il est facile de faire un plug-in qui récupère le mot de passe (il suffit de lire le fichier) et qui les envoie à un server...?

[jobherzt]

sous firefox :

edition > preferences > vie privé > mot de passe > afficher les mots de passe

et ils apparraissent tous en clair !

mais tu peux definir un mot de passe principal, que tu tapes une fois par session et qui sert a crypter/decrypter tous les mots de passe. c'est la solution la plus acceptable en terme de securité !

[jobherzt]

[cross posting]

oui, mais a priori il te demande ton avis avant d'installer un plugin.