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

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 ?

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.

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é !

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

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

md5 (md5 ($pwd));

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

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

Envoyé par bressan

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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.