Comment stocker un mot de passe en toute sécurité ? Bcrypt est-il une bonne méthode ?

[Katleen Erna]

Comment stocker un mot de passe en toute sécurité ? Bcrypt est-il une bonne méthode ?

MD5, SHA1, SHA256, SHA512, SHA-3, etc... Tous sont des algorithmes rapides destinés à calculer le hash (l'empreinte) d'une grande quantité de données en un temps aussi court que possible.

Un serveur moderne peut calculer un hachage MD5 de données à hauteur de 330 MB par seconde. Autrement dit, si vos utilisateurs ont des mots de passe alphanumériques de six caractères de long, il est possible d'essayer toutes les combinaisons possibles de cette taille en près de 40 secondes. Et ce, sans aucun investissement particulier.

Des circuits imprimés spécialisés peuvent également calculer une centaine de millions d’empreintes SHA-1/MD5 par seconde : 10.000 en parallèle et vous pouvez casser tout mot de passe de 1 à 10 caractères en une seule journée.

Si un individu malfaisant est près a débourser 2000 euros pour tenter de découvrir des mots de passe, et d'occuper deux semaines à batir son projet, il pourra par exemple se construire un cluster de super-ordinateur avec CUDA et ainsi essayer environ 700.000.000 mots de passe à la seconde. Des statistiques montrent qu'à cette vitesse, il est possible de cracker un mot de passe par seconde.

De plus, les sels sont désormais inutiles dans la prévention d'une attaque par force brute, par rainbow table ou par dictionnaire. Le sel, en informatique, c'est une chaine complémentaire qui sera combinée au mot de passe et qui va le rallonger pour compliquer la tache des attaquants.

La rapidité avec laquelle un pirate peut entrer un mot de passe potentiel ne sera pas ralentie par le hash ou le sel présent dans votre base de données.

Comment se protèger alors ?

BCrypt est un algorithme de hachage lent qui fut développé en 1999 pour OpenBSD. Son point fort, c'est qu'il demande beaucoup de temps pour calculer une empreinte et qu'il n'est pas compatible avec du matériel spécialisé. Avec cet outil, c'est le programmeur lui-même qui décide du temps de calcul d'une empreinte. Avec le réglage par défaut, un PC ne génère que 15 empreintes par seconde (ce qui est très loin des millions de calculs par seconde obtenus avec SHA-1 ou MD5, par exemple).

Les algorithmes rapides sont-ils obsolètes dans la protection de mots de passe ?

Bcrypt est-il la solution miracle pour la protection des empreintes, ou bien a-t-il des failles ?

Quelle est selon-vous la meilleure façon de protèger les mots de passe d'utilisateurs d'un site ?

[Thorna]

Hum, j'ai du mal à penser qu'un algorythme, même peu connu ou utilisé, qui date de 1999 soit encore dans le coup du point de vue sécurité.
Et je me demande aussi ce que c'est que cette histoire de sel inutile : s'il y en a au chiffrage, il en faut bien aussi pour les tentatives de déchiffrage, non ?

[rguef]

Que vaut un article si les sources ne sont pas citées ?

Edit :

http://bcrypt.sourceforge.net/

Bcrypt is a cross platform file encryption utility. [...]
Bcrypt uses the blowfish encryption algorithm published by Bruce Schneier in 1993.

[daredare]

Envoyé par Thorna

Hum, j'ai du mal à penser qu'un algotythme, même peu connu ou utilisé, qui date de 1999 soit encore dans le coup du pioint de vue sécurité.
Et je me demande aussi ce que c'est que cette histoire de sel inutile : s'il y en a au chiffrage, il en faut bien aussi pour les tentatives de déchiffrage, non ?

Hum, si je ne me trompe pas, Bcrypt est basé sur Blowfish qui date lui de 1993... et qui a été conçu par un certain Bruce Schneier, expert renommé en cryptologie/cryptographie. A ma connaissance, il n'y a pas d'attaque simple connue sur Blowfish, ce qui le rend a priori plutôt sûr (et si je ne m'abuse, Blowfish était candidat tout comme Rijndael au concours AES, c'est ce dernier qui a gagné, mais je ne me rappelle plus par contre si des éléments majeurs ont disqualifié Blowfish)...

Donc concernant la sécurité de Bcrypt, je pense (mais cela n'engage que moi ) qu'il est toujours dans le coup...

Edit :
Oups, grillé !

[rguef]

De même, Blowfish est un algorithme de chiffrement symétrique, et non de hashage. BCrypt étant basé dessus, il ne donne pas de hash mais bien un fichier chiffré.

Edit:
Apparemment il existe une commande "bcrypt" pour le hashage sour OpenBSD
www.openbsd.org/papers/bcrypt-paper.ps

L'article ne parle donc pas de l'utilitaire Bcrypt, mais bien de la commande bcrypt...

[lochnar]

Envoyé par Thorna

Hum, j'ai du mal à penser qu'un algotythme, même peu connu ou utilisé, qui date de 1999 soit encore dans le coup du pioint de vue sécurité.
Et je me demande aussi ce que c'est que cette histoire de sel inutile : s'il y en a au chiffrage, il en faut bien aussi pour les tentatives de déchiffrage, non ?

le but du sel est de rallonger le mot de passe afin que cela complique la tâche de celui qui voudrait déchiffrer le mot de passe sans le connaitre...

Côté code, toi tu connais le sel et où il est placé par rapport au mot de passe, l'utilisateur connait son mot de passe. A l'identification tu n'as plus qu'a combiner les 2 pour vérifier la bonne authentification de la personne ^^

[Marco46]

Les algorithmes rapides sont-ils obsolètes dans la protection de mots de passe ?

Ben si ne m'abuse beaucoup de sites bloquent le compte pendant n minutes au bout de n tentatives de connexion ratées ...

Du coup ça fait pas des centaines de millions de tentatives à la seconde ça.

Donc je dirais que non.

Bcrypt est-il la solution miracle pour la protection des empreintes, ou bien a-t-il des failles ?

Je crois pas trop aux miracles

Quelle est selon-vous la meilleure façon de protèger les mots de passe d'utilisateurs d'un site ?

Un hash SHA-1 du login + mot de passe en BDD non ?

[vanquish]

Envoyé par Marco46

Ben si ne m'abuse beaucoup de sites bloquent le compte pendant n minutes au bout de n tentatives de connexion ratées ...

Du coup ça fait pas des centaines de millions de tentatives à la seconde ça.

tout dépend on s'attaque à un site, ou à une copie de la base de donnée où sont stocker les hash.

L'article parle de "site", il faut donc ajouter les temps de communications et de prise en compte de la requête.

Même sur un site très réactif, je ne pense pas que l'on puisse faire 700.000.000 requêtes par seconde.

Envoyé par Katleen Erna

si vos utilisateurs ont des mots de passe alphanumériques de six caractères de long

Tout le problème est là ! Ne pas laisser la possibilité de définir des mots de passe trop faible.

De toute façon le maillon faible reste définitivement l'utilisateur.

Un jour, pour la mise en place d'un nouveau serveur, j'ai vu un technicien du service informatique appeler au téléphone une quinzaine de personnes pour leur réclamer leur login et mot de passe. "Bonjour, c'est le service informatique, j'aurais besoin ......"
Il n'a essuyé aucun refus.

Je me ballade dans ces établissements, m'installe à un poste laissé vacant par son utilisateur - sans verrouillage - sans que personne ne me demande rien.
Si on me demande, je réponds "je suis l'informaticien" et ça s'arrête là.

Je ne parle même pas des post-it sur l'écran.

Je ne dis pas qu'il faut tout stocker en clair, mais le développeur peut faire tout ce qu'il veut, il ne peut pas lutter contre la mauvaise éducation des utilisateurs, voir de de certains (mauvais) administrateurs (si, si ça existe).

Qu'est-ce que les pirates utilisent le plus : la force brute ou le bête fishing ?

[dams78]

Très intéressant cet article, une fois de plus on remarque le professionnalisme des BSD (je vais finir par y passer si ça continue...).

Sinon il y avait un point que j'avais remarqué, c'est qu'effectivement un bon système de sécurité ne repose pas sur un seul point, si on permet à l'utilisateur de ne saisir son mot de passe que X-fois où bien si à chaque échec on l'oblige à attendre X secondes cela permet d'empêcher tous ces "robots".
Par contre comme il a été dit, s'il s'agit d'une copie de table... Bien qu'avec le sel stocké ailleurs cela permet de résoudre ce soucis.

Après c'est claire que le soucis provient de la non formation des utilisateurs, tout en sachant que les concepteurs sont aussi pour moi des utilisateurs. Quand je vois des sites qui tous les mois m'envoient "en claire" mon mot de passe, je vois rouge. Pareil tout à l'heure pour me connecter à mon Intranet j'ai été obligé de donner un mot de passer par téléphone et comme je suis pas au siège, je ne peux pas le changer...

[kain_tn]

pourquoi est-ce que le sel est devenu inutile?

[Inazo]

Bonjour à tous,

Alors faisons le tour vite fait :

L'actualité commence avec ceci :

MD5, SHA1, SHA256, SHA512, SHA-3, etc..

Et on ne parle plus des SHA256,512 et -3 dans la news... Cela fait plus de trois ans que les MD5 et SHA1 sont déclaré comme obsolète...

Ensuite :

De plus, les sels sont désormais inutiles dans la prévention d'une attaque par force brute, par rainbow table ou par dictionnaire. Le sel, en informatique, c'est une chaine complémentaire qui sera combinée au mot de passe et qui va le rallonger pour compliquer la tache des attaquants.

Faux. Car aucune ancienne protection ne doit être mise de côté de manière si systématique. Pourquoi ? Simplement si on attaque une copie de base et que l'on ne connait pas la position du sel on peut toujours courir quelque temps même si on a le sel. Et si on a pas le sel, il mettra encore plus de temps. En plus il faut définir de quel attaque par force brute on parle, sois en direct sur la BDD soit via l'interface de connexion de l'application visée.

Si c'est via l'interface de connexion, oui le sel ne sert a rien mais le Hashage aussi ne sert a rien...

Ensuite :

De même, Blowfish est un algorithme de chiffrement symétrique, et non de hashage.

Si c'est exact, en effet on ne peut pas comparé Blowfish au MD5 ou autre SHA. Car chiffrement permet le déchiffrement, le hashage lui non.

Après il faut savoir que des dictionnaires de MD5 se sont constitué à travers le monde de part ça grande utilisation dans les applications web.

Donc de toute façon dans les applications récentes on ne devrait plus trouver du MD5 et du SHA1, et avoir au moins une chaine de sel, soit unique par compte soit générale pour l'application. De toute manière en cas de vol de votre BDD vous êtes dans la mer**e...

Et pour finir :

Tout le problème est là ! Ne pas laisser la possibilité de définir des mots de passe trop faible.

Tout a fait d'accord ! On pourrait aussi faire comme Twitter et bloqué les mots de passe trop simple, ou récupérer des dictionnaires de mot de passe et bloqué ceux qui s'y trouve, mais là c'est vraiment long et pas forcément judicieux...


Car exemple de MD5 : 2b4a5d74761be777cdd5d695c16ffc58

J'ai un sel dans ce MD5 et vous ne le connaissez pas... Vous l'attaquez comment ? Par double attaque de dictionnaire... Long très très long... A moins que vous ayez réussi a insérer un compte à vous dans l'application et donc vous connaissez votre MDP. Mais pas la taille du sel. Ni son emplacement... Car par définition le MD5 = 32 caractères et ceci TOUJOURS !

Donc si mon sel est "7c412825f7dfa7675f8e9352997a0544" et que je l'ai placé après le X caractères de votre MDP... Je vous souhaites bien du courage...

Le sel reste une protection efficace dans certain cas. A condition que son emplacement et ou ça valeur ne transpire pas. Dans l'exemple que j'ai donnée je serais attaquant et me rendant compte qu'il y a un sel et que je ne connait pas ça position je poursuivrais mon attaque pour trouver ces informations. Mais là on est hors du cadre de la protection des algorithmes de Hash.

Cordialement,

[bressan]

Et si on crypte des mots de passe avec sels et md5 deux fois, genre :

md5 (md5 ($pwd));

(Je code en PHP, donc je prends cet exemple de code).

Ça ne rend pas les choses beaucoup plus compliquées ???

[Inazo]

Oui c'est plus compliqué mais je le répète de manière plus claire le MD5 est obsolète. John The Ripper, fameux logiciel du genre, a été annoncé il y a quelque année comme ayant cassé le md5... Et quand on parle de casser c'est à dire de faire ce qui en théorie n'est pas possible avec le md5 c'est a dire le dé-hasher (désolé j'ai pas de termes plus français en tête).

Donc il est tout de même vivement conseiller de passer a des algorithmes de hashage du niveau du SHA-256, le SHA1 étant lui aussi obsolète.

Cordialement,

[ctxnop]

Envoyé par bressan

Et si on crypte des mots de passe avec sels et md5 deux fois, genre :

md5 (md5 ($pwd));

(Je code en PHP, donc je prends cet exemple de code).

Ça ne rend pas les choses beaucoup plus compliquées ???

Non, ca ne rend pas du tout les choses plus compliquées, au lieu de trouver un mot de passe on trouvera un autre hash md5. Et ca se reconnait immédiatement. Il suffit donc de recommencer. C'est juste un peu plus long, mais sur du md5, ca va pas pourrir les vacances du hacker.

[Inazo]

Non, ca ne rend pas du tout les choses plus compliquées, au lieu de trouver un mot de passe on trouvera un autre hash md5. Et ca se reconnait immédiatement. Il suffit donc de recommencer. C'est juste un peu plus long, mais sur du md5, ca va pas pourrir les vacances du hacker.

Ca dépend, si j'ai un mot de passe de 32 caractères alphanumérique ce n'est pas pour autant un md5. De plus il évoque tout de même l'utilisation de "sel".

Il est vrais que c'est fort reconnaissable et que faire du double ou triple, voir plus, md5 n'est pas vraiment utile mais ça peut ralentir un tout petit peu, surtout si à chaque fois on utilise en sel différent...

Cordialement,