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

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).

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

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

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

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 ?

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

Edit :

http://bcrypt.sourceforge.net/

Citation:

---

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

---

Citation:

---

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 :zoubi: ) qu'il est toujours dans le coup...

Edit :
Oups, grillé ! :mouarf:

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... ;)

Citation:

---

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 ^^

Citation:

---

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.

Citation:

---

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

---

Je crois pas trop aux miracles :aie:

Citation:

---

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 ?

Citation:

---

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.

Citation:

---

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 ?

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... :ccool:

pourquoi est-ce que le sel est devenu inutile? 8O

Bonjour à tous,

Alors faisons le tour vite fait :

L'actualité commence avec ceci :

Citation:

---

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 :

Citation:

---

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 :

Citation:

---

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 :

Citation:

---

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,

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

Code:

---

md5 (md5 ($pwd));

---

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

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

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,

Citation:

---

Envoyé par bressan

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

Code:

---

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.

Citation:

---

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,

Citation:

---

Envoyé par Inazo

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,

---

Ouais enfin, déjà que c'est dur de faire comprendre aux utilisateurs qu'il faut utiliser des mots de passes de plus de 6 caractères, alors 32... Sans compter que la plupart des site n'autorisent pas une telle taille de mot de passe. Et pour finir, la très grande majorité du temps, quand on obtient les mots de passes en versions hashé on en obtient pas juste un seul, il faudrait que tous ces mots de passes soient ressemblent à du md5. Pour le peu que ca ralenti, ca ne vaut vraiment pas le coup. Enfin je trouve. C'est pareil que faire un fichier Zip contenant un autre fichier Zip. La compression résultante est totalement négligeable et à force de ziper et re-ziper, le fichier finit par être plus gros que le zip d'origine.
A la limite, si tu veux faire du double/triple/... hash, tu utilises des fonctions différentes. Comme md5, puis sha-X, ...., et tu les appliques dans un ordre différents mais déterminable. Genre, en fonction de l'heure d'inscription, si c'est une minute paire alors md5 puis sha, sinon sha puis md5. Le tout en utilisant du bourrage par bruit (aléatoire) pour faire correspondre la taille des petites sommes à celles des grandes.
Et là tu fera perdre un peu de temps à l'attaquant. Il verra toujours que tu fais du double/triple/... hachage, mais il ne pourra pas distinguer les types de hash utlisé ni l'ordre.

Mais déjà, faire croire à l'utilisation d'un autre hachage ralentit beaucoup.
Par exemple, admettons qu'on utilise le md5, sa taille sera de 32 caractère, celle du SHA-512 est de 64 catactères. On pourrait donc créer une chaine de 64 caractères aléatoirement et injecter le md5 dans cette chaine, soit à une position fixe, soit à une position déterminable (je reprend l'exemple de l'heure de l'inscription). Du coup l'attaquant va croire qu'on a utilisé un sha-512, alors qu'en fait on a utilisé un md5. Je doute qu'il comprenne ca en 10 secondes. Une fois qu'il aura compris, faudra encore qu'il trouve le véritable hash utilisé (potentiellement n'importe quel hash de moins de 64 caractère peut être utilisé. En prime il doit comprendre que le md5 n'est pas toujours au même endroit, et pour finir il doit comprendre le schéma utilisé pour positionner le md5. Là, avec ce genre d'astuces, tu fais perdre du temps à l'attaquant. Mais juste faire un double md5, tu lui fais perdre 10 secondes.

Edit: évidemment, si l'attaquant obtient le code, aucune astuce de ce type ne le ralentira.

Ok, ok, j'étais dans le faux.
Il faudrait donc que je m'intéresse à l'algorithme de chiffrement Blowfish dont vous parliez précédemment.
Ça devrait d'ailleurs être (a priori) plus efficace et sûrement plus simple que de faire n md5 entrecoupés de n sha-X suivant l'heure avec des sels différents ...

Ben bcrypt est peut être connu dans le monde la crypto. Mais pour le dev web, c'est la première fois que je rencontre (j'ai pas tout vu, tout lu, mais bon).
Donc j'ai envie de dire que sa force fera sa faiblesse. Aujourd'hui il n'y à pas de matériel pour cracker du bcrypt rapidement. On disait la même chose de ces cryptages sha et md5 auparavant. Et aujourd'hui ils sont considérés comme non fiable. Donc demain si le succès rencontre bcrypt, le hardware pour le cracker suivra inévitablement.

La question est plutôt bcrypt pourra t'il tenir plus longtemps que sha ou md5 ?

Car quelque chose dont personne ne parle, c'est qu'aujourd'hui, en ce qui me concerne, j'ai des bdd qui utilise sha (par contraintes plus que par choix) mais à la vu du volume de données à traiter, je me voit mal cracker tout les hash, pour ensuite les ré encrypter pour un truc plus sur si jamais la demande m'était faite......


Maintenant en ce qui concerne le grain de sel, à 700 000 000 de mots de passe à la seconde...... Cela me semble rapide de trouver le grain de sel si on à un mot de passe en clair et son empreinte.

@ctxnop
Aussi j'aurais bien aimé comprendre comment vous faites pour ré hasher des mots de passes, à des fins comparatives, alors que les passwords sont enregistrés en bdd avec des sels différents et variants dans le temps.

Un md5 de md5, il y a très peu de chances que ça ai l'air d'un md5 après premier décodage.

C'est le principe du hachage qui veux ça.

Sinon, on peu faire des password jetables (à n utilisations).

On hache le password n fois et on stocke sur le serveur. Pour authentifier, le serveur envoie la requête n-1 au client. le client hache n-1 fois le password et l'envoie au serveur. Le serveur hache une fois et vérifie que le pass est le bon. Si oui, il enregistre le hach au rang n-1, et demandera n-2 à la prochaine connexion.

Bien sur, il faut éviter que n n'arrives à 0.

Comme je l'ai dit le hash de hash doit être fait de manière intelligente. Donc par exemple avec utilisation de sel différent a chaque fois.

Juste une toute petite correction :

Citation:

---

SHA-512 est de 64 catactères

---

C'est faux, c'est la taille du sha256 ça... Le SHA-512 est à 128 caractères non ?

Bref pour finir si vous souhaitez utiliser des hash de hash de faites pas simplement :

Code:

---

1 2	md5(md5(sha1('toto')))

---

Car comme la justement dit ctxnop

Un hash de hash simple ça se voit quand même comme le nez au milieu de la figure, car après décodage tombé sur une chaine de 32 ou 41 voir 64 ça laisse perplex ^^.

Cordialement,