Sécurité des mots de passe

Signaler
Messages postés
7
Date d'inscription
mardi 18 septembre 2007
Statut
Membre
Dernière intervention
24 novembre 2011
-
Messages postés
7
Date d'inscription
mardi 18 septembre 2007
Statut
Membre
Dernière intervention
24 novembre 2011
-
Bonjour,

Je projette d'écrire un sujet sur la sécurité des sites web en général et je souhaiterai avoir quelques précisions sur les mots de passe, afin de ne pas écrire de bêtise, même si mes questions vont bien au-delà des points techniques que je souhaiterai aborder.

J'ai donc plusieurs questions :

base64_encode() est bien une fonction réversible ? (question rhétorique en fait, mais c'est pour être sûr que j'ai compris)

L'idée de faire une boucle avec cette fonction pour crypter un mot de passe est-elle risible ? même en faisant une boucle de 100 itérations ?


La fonction md5() n'est pas réversible car elle génère un hash ? (question rhétorique encore)

Peut-on affirmer que les CMS open sources PHP tels Wordpress ou Drupal ne stockent jamais de mot de passe en clair, mais des hashs ? crypt, md5 ou sha1 d'ailleurs ?


Plus compliqué...

Sachant que la fonction md5() génère toujours un hash de 32 caractères composé de lettre minuscules et de chiffres, peut-t-il y avoir un hash identique pour 2 mots de passe différents si $salt reste le même ? (la question marche avec sha1, 40 caractères, majuscules et chiffres)

Si la réponse à la question précédente est oui, et en se basant sur un mot de passe composé de minuscule, majuscule, chiffre, ponctuation, bref tout ce qu'on peut taper avec un clavier occidental, existe-t-il un nombre optimal de caractère pour un mot de passe ?

En effet, s'il existe plusieurs solutions pour un hash, il y en a obligatoirement une (ou deux) plus courte que les autres non ?

Merci d'éclairer ma lanterne..

5 réponses

Messages postés
14828
Date d'inscription
vendredi 14 mars 2003
Statut
Modérateur
Dernière intervention
18 novembre 2021
157
Bonjour,

1) base64_encode, comme son nom l'indique encode la donnée, donc pas de cryptage et réversible.
2) En général on préfère hasher un mdp plutôt que le crypter.
Mais dans le cas de coordonnées bancaire, le cryptage (si on stocke l'information) est une base, car un numéro de carte hashé n'a aucune utilité.
3) MD5 (tout comme SHA1) n'est pas réversible
4) Oui, ça s'appelle des collisions, pour un même hash, il existe plusieurs chaines sources possible.
5)Pour retrouver un mdp à partir d'un hash, il faut y aller par brute-force, mais utiliser un mot de passe compliqué ne garanti pas qu'un mdp plus simple ne puisse donner le même hash.

Actuellement, il y a des techniques pour retrouver une chaine source pour un hash MD5 (lourd, mais techniquement et temporellement possible), de fait, on lui préfère SHA1 maintenant.

---------------------------------------------------------------------
[list=ordered][*]Pour poser correctement une question et optimiser vos chances d'obtenir des réponses, pensez à lire le règlement CS et aussi ce lien[*]Quand vous postez un code, merci d'utiliser la coloration syntaxique (3ième icône en partant de la droite : )
[*]Si votre problème est résolu (et uniquement si c'est le cas), pensez à mettre "Réponse acceptée" sur le ou les messages qui vous ont aidés./list
---
Mon site
Messages postés
7
Date d'inscription
mardi 18 septembre 2007
Statut
Membre
Dernière intervention
24 novembre 2011

Merci pour cette réponse rapide !
Messages postés
1309
Date d'inscription
samedi 31 janvier 2009
Statut
Membre
Dernière intervention
5 juin 2013
14
Salut,

Ha, voici un sujet intéressant :)
Je vais commencer par me faire un peu de pub en recommandant un article que j'ai écrit à ce sujet : Chiffrement, hachage et compagnie : disambiguation. Ceci fait, je me permet de compléter la réponse donnée par NHenry.

Sachant que la fonction md5() génère toujours un hash de 32 caractères composé de lettre minuscules et de chiffres

Oui et non. Quand on calcule le md5 de quelque chose, on génère un hash stocké sur 128 bits. Afin de représenter ce hash on va utiliser une notation hexadécimale, et donc 32 chiffres allant de 0 à F (oui, en base 16 on va utiliser les premières letrtes de l'alphabet afin de compléter les chiffres manquants).

peut-t-il y avoir un hash identique pour 2 mots de passe différents si $salt reste le même ? (la question marche avec sha1, 40 caractères, majuscules et chiffres)

mais utiliser un mot de passe compliqué ne garanti pas qu'un mdp plus simple ne puisse donner le même hash.

Comem NHenry l'a dit, une colision est possible. Cependant je tient à relativiser cette possibilité. Dans le cadre du md5, le nombre de possibilités est de (plusieurs notations) :
2^128
16^32
340282366920938463463374607431768211456
Soit approximativement 3.4*10^38

Il faut savoir que le corps humain est composé d'environ 10^27 atomes et la terre 10^50. Alors avec de l'ordre de 10^38 possibilités il y a de la marge, énormément de marge. Si, pour md5, il est possible de créer des colisions (lorsqu'on connais la donnée de base il me semble), le risque d'avoir par erreur une telle colision est ridiculement faible, et a vrai dire totalement négligeable.

Si la réponse à la question précédente est oui, et en se basant sur un mot de passe composé de minuscule, majuscule, chiffre, ponctuation, bref tout ce qu'on peut taper avec un clavier occidental, existe-t-il un nombre optimal de caractère pour un mot de passe ?

Comme toujours, il faut maximiser la longueur ainsi que le jeu de caracctères utilisés et bien entendu éviter les mots du dictionnaire (même écrits en |_337). Certains recommandent d'utiliser de simples phrases qui, bien que le jeu de caractères soit restreint, ont l'avantage d'être très longues et faciles à retenir.

Au passage, regarde donc un peu du côté des rainbow tables ainsi que de John the Ripper.
Messages postés
2378
Date d'inscription
lundi 4 février 2002
Statut
Membre
Dernière intervention
29 décembre 2012
18
Pas mieux que mes collègues !!
S.
Messages postés
7
Date d'inscription
mardi 18 septembre 2007
Statut
Membre
Dernière intervention
24 novembre 2011

Merci pour ces précisions TychoBrahe, ton blog est très intéressant, particulièrement ton article sur les vulnerability scanners.