Crypter les mots de passe utilisateurs

Version imprimable

05/08/2010, 22h10
la_praline

Crypter les mots de passe utilisateurs

Bonjour,

Je me lance dans la réalisation d'une application qui s'appuie sur jdbc et une base de données mysql. Pour mes utilisateurs je souhaiterai trouvé une solution qui me permettrait d'enregistrer mes mot de passe de manière crypté.
Seul soucis je ne sait pas quel algo de crypto utilisé ou comment l'implémenter en java.

Merci de votre aide
06/08/2010, 00h18
tchize_

Java cryptography extension contient toutes les méthodes pour chiffre. Pour l'algo, utiliser du SHA-256 (pas du SHA-1 !) ou éventuellement du md5 (considéré comme moins sur aujourd'hui mais plus répandu)
06/08/2010, 01h00
la_praline

Merci je vais y jeter un coup d'oeil :D
06/08/2010, 16h55
Marco46

Notes que les algorithmes présentés par tchize_ ne sont pas des algos de chiffrement mais des algos de hash (ou condensat, ou empreinte numérique).

Ils donnent en sortie une séquence de longueur fixe unique (en théorie) pour chaque mot donné en entrée.
07/08/2010, 09h55
la_praline

Pourrais tu expliciter tes dires ?
07/08/2010, 10h12
Uther

Pour une explication des fonctions de hashage : http://fr.wikipedia.org/wiki/Fonction_de_hachage

Pour faire simple si ton mot de passe est "mot de passe" et que tu le passes par l'algorythme sha-256, tu obtiens "1d894561b306ded29257d6acc1689003c4f484010c39324a08fd66c4a1068ee4", ce que l'on appelle un hash.
Il n'y a pas de manoeuvre connue pour faire operation inverse.

Pour vérifier le mot de passe il faudra donc que tu calcules le hash du mot de passe saisi par l'utilisateur et que tu le compare avec le hash stoqué en base.

Normalement il ne doit pas non plus exister de méthode connue pour connaitre une chaine qui ait le même hash qu'un chaine déjà connue. Ce n'est plus le cas des algorithmes sha-1 et md5, c'est pourquoi ils sont déconseillés pour des utilisation de somme de controle.
Ceci dit pour stoquer des mot de passe je ne voit pas vraiment ou est le problème car pour trouver un second mot de passe valable, il faudrait déjà connaitre le premier(et sa longueur dépacerai de toute façon probablement la taille limite)
09/08/2010, 10h48
Marco46

Citation:

Envoyé par Uther

Normalement il ne doit pas non plus exister de méthode connue pour connaitre une chaine qui ait le même hash qu'un chaine déjà connue. Ce n'est plus le cas des algorithmes sha-1 et md5, c'est pourquoi ils sont déconseillés pour des utilisation de somme de controle.

Le croyais que seul MD5 avait été cassé ?

Ceci dit, il faut bien voir que ce cassage est un projet de recherche universitaire qui a pris des années. C'est très loin d'être à la portée du premier venu.

Citation:

Envoyé par Uther

Ceci dit pour stoquer des mot de passe je ne voit pas vraiment ou est le problème car pour trouver un second mot de passe valable, il faudrait déjà connaitre le premier(et sa longueur dépacerai de toute façon probablement la taille limite)

J'ai rien compris :aie:

Sinon je voulais juste dire que stocker les mots de passes en BDD tels quels c'est vraiment le minimum en terme de sécurité et c'est pas terrible. Il existe des BDD de hash qui permettent de trouver le mot en clair correspondant à tel hash.

Donc pour une meilleure protection, cf salage.
09/08/2010, 11h11
tchize_

Citation:

Envoyé par Marco46

Le croyais que seul MD5 avait été cassé ?

Ceci dit, il faut bien voir que ce cassage est un projet de recherche universitaire qui a pris des années. C'est très loin d'être à la portée du premier venu.

En fait, pour les mots de passe "courant", c'est à la porté du premier venu. Le md5 et tellement utilisé qu'il suffit de tapper en général le md5 dans google pour trouver une page contenant à la fois le md5 et le mot d'origine. Exemple, si mon mot de passe est "Colombie", j'obtiens "b9d86ddfc0069a6dbcaa686afd98ca56". Si je tappe ça dans google, j'obtiens http://www.xing.com/uk/directories/p...a686afd98ca56/

Pareil, si mon mot de passe est poulet, le md5 est 5337aff4d7c42f4124010fc66bcec881, j'envoie dans google et j'ai poulet écrit partout ;)

D'un manière générale, les analyse et les démonstrations de collisions sont la preuve que le md5 est sensible aux attaques autres que par force brute. C'est suffisant du point de vu cryptanalyse pour rejeter l'utilisation de cet algorithme dans des domaines liés à la sécurité. Surtout que des alternative comme SHA-156 existent.

Citation:

Donc pour une meilleure protection, cf salage.

+1 ;)
09/08/2010, 14h37
Uther

Citation:

Envoyé par Marco46

Le croyais que seul MD5 avait été cassé ?

Autant pour moi. Après vérification, il y a des doutes sur des risques de collision mais pour le moment le sha-1 n'a pas été cassé.

Citation:

Envoyé par Marco46

Sinon je voulais juste dire que stocker les mots de passes en BDD tels quels c'est vraiment le minimum en terme de sécurité et c'est pas terrible. Il existe des BDD de hash qui permettent de trouver le mot en clair correspondant à tel hash.

Donc pour une meilleure protection, cf salage.

En effet, je n'ai pas précisé car je voulais rester simple et que c'était précisé dans l'article en lien. Mais le salage apporte une sécurité supplémentaire.

Citation:

Envoyé par Marco46

J'ai rien compris

Ce que je voulais dire c'est que les fonction de hashage comme md5 et sha-1 sont sensé garantir 2 choses:
- à partir du hash, on ne sait pas recalculer la chaine d'origine.
- on ne sait pas obtenir deux chaines d'originales différentes qui ont un hash identique (ce qu'on appelle une collision).

On sait trouver des collisions dans le md5, mais on ne sait toujours pas revenir au résultat d'origine autrement que par des tables précalculées.

Dans le cas particulier du stockage de mot de passe, je ne voit pas vraiment pourquoi les collisions seraient un problème.
Par contre c'est sur que pour d'autres usages, il est clairement a bannir.
09/08/2010, 14h49
tchize_

Citation:

Envoyé par Uther

- on ne sait pas obtenir deux chaines d'originales différentes qui ont un hash identique (ce qu'on appelle une collision).

je me permet un bémol "pour autant que le message à hasher soit plus court que la message hashé". Pour les message plus long, la collision est inévitable :) (pour un hash de 160bits et un message de 170bit, il y a donc 2^10 fois plus de message possible que de hash possible).

Citation:

Dans le cas particulier du stockage de mot de passe, je ne voit pas vraiment pourquoi les collisions seraient un problème.

C'est là que réside le problème collision dans mot de passe = plus grande facilité de construire un mot de passe (même mauvais) qui correspond hash.
C'est d'ailleurs plus dans la possibilité d'exploiter une collision que son existence qui pose problème (formules permettant de construire un message T2 même incohérent qui aurait un hash bien précis). Bien sur dans ce dernier cas, à la place du mot de passe toto, tu te retrouvera peut-être à tapper rvzervz&ç'"ob_%hzz!é55ùrvhéç'!1vzziuy1 pour avoir le même hash :mouarf:
09/08/2010, 16h55
hibour

Pour les algorithmes de cryptage on a 3DES, AES http://en.wikipedia.org/wiki/Cryptog...y_cryptography avec une clé (mot de passe) de 128 à 256bits.
A++
09/08/2010, 17h11
Marco46

Citation:

Envoyé par hibour

Pour les algorithmes de cryptage on a 3DES, AES http://en.wikipedia.org/wiki/Cryptog...y_cryptography avec une clé (mot de passe) de 128 à 256bits.
A++

Certes mais ce n'est pas une solution appropriée à son problème. Chiffrer un mot de passe avec une clef qui n'est rien d'autre qu'un mot de passe, c'est le problème de la poule et de l'œuf. On en sort jamais.
09/08/2010, 17h26
hibour

Citation:

Envoyé par Marco46

Certes mais ce n'est pas une solution appropriée à son problème. Chiffrer un mot de passe avec une clef qui n'est rien d'autre qu'un mot de passe, c'est le problème de la poule et de l'œuf. On en sort jamais.

Pourquoi? 8O
09/08/2010, 17h57
tchize_

parce que si tu fais

clé = motdepasseutilisateur
donnée = motdepasseutilisateru
crypterAvecAlogorithmeSymétriqueX(clé, donnée)

tu va avoir plusieurs problèmes
1) tu as une répétition (le mot de passe est utilisé à la fois comme clé et donnée), les répétitions sont une source puissante d'attaque par cryptanalyse
2) tu n'a plus de garantie du tout quand au collision
3) un mot de passe utilisateur c'est en général 5 à 8 chiffre. Un cryptage comme AES c'est 128bits pour la clé. En utilisant un tel cryptage, tu ouvre un faille supplémentaire puisque tu limite volontairement l'espace de clés

La pratique veux qu'on utilise correctement un algo de hash existant et éprouvé plutot d'inventer le sien, ceci évite des erreurs dangereuses.
09/08/2010, 20h50
Uther

Citation:

Envoyé par tchize_

je me permet un bémol "pour autant que le message à hasher soit plus court que la message hashé". Pour les message plus long, la collision est inévitable :) (pour un hash de 160bits et un message de 170bit, il y a donc 2^10 fois plus de message possible que de hash possible).

En effet sur les messages longs, il est évident qu'il y aura forcément des collisions possible. L'essentiel étant qu'on ne sache pas trouver un message avec un hash identique à un message donné.

Citation:

Envoyé par tchize_

C'est là que réside le problème collision dans mot de passe = plus grande facilité de construire un mot de passe (même mauvais) qui correspond hash.

Je n'arrive toujours pas à voir en quoi c'est un problème pour stoker un mot de passe. Pour essayer de calculer un un mot de passe avec un hash identique, il faudrait déjà connaitre le mot de passe d'origine ...
Et en cas d'attaque par dictionnaire ou en bruteforce, le vrai mot de passe sera de toute façon trouvé bien avant un mot de passe en collision(car il sera bien plus long et complexe).
09/08/2010, 21h34
tchize_

effectivement, je n'ai peut etre pas tout bien lu (on parle plus d'utiliser ces technique pour fausser des signatures) de toutes façons, on recommande d'abandonner le md5 pour sha-256, pourquoi se priver :D .
10/08/2010, 10h17
hibour

On encrypte le mot de passe avec une clé fixe sauvegardée dans la base de donnée par exemple pour ne pas le mettre en clair dans le code.
10/08/2010, 10h41
Marco46

Citation:

Envoyé par hibour

On encrypte le mot de passe avec une clé fixe sauvegardée dans la base de donnée par exemple pour ne pas le mettre en clair dans le code.

Donc si je comprends bien ta démarche, pour sauvegarder un mot de passe de manière sécurisée dans une base de données, tu chiffres ce mot de passe avec une clef... que tu enregistres dans la BDD 8O ?

Le chiffrement ne résoud rien puisque pour chiffrer il faut une clef. Comment chiffrer la clef ayant permis de chiffrer ayant permis de ... etc ... On en sort pas.

Le seul moyen c'est de demander à chaque utilisation du soft la saisie d'un mot de passe qui servira alors de clef et là vous pouvez chiffrer un fichier de config par exemple mais ce mot de passe sera enregistré en tant que hash avec un salt.

Sinon en dernier recours il y a le support externe pour un certificat X.509 + clef privée mais c'est de l'artillerie lourde.
10/08/2010, 11h45
tchize_

le principe du hash c'est justement de ne jamais décrypter le mot de passe, ce qui protège les utilisateur contre le vol de ce genre d'information par un administrateur ou une personnes trouvant le moyen de voler les bases de données.

Alors tout d'abord je suis heureux de voir que mon topic crée débat et j'en apprends bcp sur le sujet grâce à vous. Je me suis lancé dans l'élaboration du code qui me permettra d'intégrer le mot de passe crypté dans ma base mais il ne ressemble pas trop à ce que je m'imaginai

Voilà le résultat
Code:

1 2 Hash : [B@1b3c607
voilà ma fonction
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 public void userRegistration(userSubscription user) { MessageDigest md; String algorithm="SHA-256"; String hash; Date date = new Date(System.currentTimeMillis()); java.sql.Date sqlDate = new java.sql.Date(date.getTime()); Timestamp time = new Timestamp(sqlDate.getTime()); //Password encryption try { md=MessageDigest.getInstance(algorithm); hash=md.digest(user.getPassword().getBytes("UTF-8")).toString(); System.out.println("Hash : " + hash); } catch (NoSuchAlgorithmException e) { System.out.println("L'algo n'existe pas !!"); e.printStackTrace(); } catch (UnsupportedEncodingException e) { System.out.println("L'encodage n'est pas bon"); e.printStackTrace(); } //userDao.insertUserAccess(user,time); //userDao.insertUserInformations(user); }
Je pensais que j'allais obtenir un hash de 64 caractères

Finalement je pense avoir trouvé le bon algo car j'obtiens des chaines de caractères en hexadécimal qui font de 62 à 64 caractères je met le code ici qui pourrais servir à d'autres égarés comme moi :D

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
        public void userRegistration(userSubscription user)
	{
		MessageDigest md;
		String algorithm="SHA-256";
		byte[] hash;
 
		Date date = new Date(System.currentTimeMillis());
		java.sql.Date sqlDate = new java.sql.Date(date.getTime());
		Timestamp time = new Timestamp(sqlDate.getTime());
 
		//Password encryption
		try 
		{
			md=MessageDigest.getInstance(algorithm);
			hash=md.digest(user.getPassword().getBytes("UTF-8"));
			StringBuilder sb = new StringBuilder(hash.length*2);
			for (byte b : hash) {
				sb.append( String.format("%x", b) );
			}
			user.setPassword(sb.toString());
		} 
		catch (NoSuchAlgorithmException e) 
		{
			System.out.println("L'algo n'existe pas !!");
			e.printStackTrace();
		}
		catch (UnsupportedEncodingException e) 
		{
			System.out.println("L'encodage n'est pas bon");
			e.printStackTrace();
		}
		//userDao.insertUserAccess(user,time);
		//userDao.insertUserInformations(user);
	}

10/08/2010, 19h29
tchize_
non, tu obtiens un array de byte (byte[]) de la longeur correspondant à l'algorithme de hash choisie (dans ton cas 256 bits, soit 32 bytes). A toi maintenant de convertir ce byte[] en String. Tu peux par exemple utiliser sa représentation hexadécimale

Version bourrin qui devrais marcher:
Code:

1 2 3 4 5 hash=md.digest(user.getPassword().getBytes("UTF-8")); StringBuilder result = new StringBuilder(); for (byte b : hash){ result.append(String.format("%2x",b); }
edit: le "2" a de l'importance, il force le byte à prendre 2 caractères ;)

Ca change bien quelquechose j'ai toujours un password crypté de 64 caractères cette fois ci cool merci du conseil voilà je redonne l'algo au cas où ça intéresserait quelqu'un

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
	public void userRegistration(userSubscription user)
	{
		MessageDigest md;
		String algorithm="SHA-256";
		byte[] hash;
		String password="";
 
		Date date = new Date(System.currentTimeMillis());
		java.sql.Date sqlDate = new java.sql.Date(date.getTime());
		Timestamp time = new Timestamp(sqlDate.getTime());
 
		//Password encryption
		try 
		{
			md=MessageDigest.getInstance(algorithm);
			hash=md.digest(user.getPassword().getBytes("UTF-8"));
			StringBuilder sb = new StringBuilder(hash.length*2);
			for (byte b : hash) {
				sb.append( String.format("%2x", b) );
			}
			password = sb.toString();
		} 
		catch (NoSuchAlgorithmException e) 
		{
			System.out.println("L'algo n'existe pas !!");
			e.printStackTrace();
		}
		catch (UnsupportedEncodingException e) 
		{
			System.out.println("L'encodage n'est pas bon");
			e.printStackTrace();
		}
		userDao.insertUserAccess(user,time,password);
		userDao.insertUserInformations(user);
	}

11/08/2010, 15h24
hibour

Le problème de sauvegarde d'un hash du password c'est que si jamais l'utilisateur perd son mot de passe il ne poura plus se reconnecté et on n'a pas de moyen de le lui renvoyer..
11/08/2010, 15h27
tchize_

en général pour ce cas là, on utilise une procédure de nouveau mot de passe (envoi d'un token et tout le bazard).

Si le mot de passe doit être décryptable, alors il n'y a plus aucun intérêt à le crypter dans la DB.

Fuseau horaire GMT +2. Il est actuellement 18h11.