Discussion :

[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]

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

[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]

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.

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

[lochnar]

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

[Jenna]

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

Pas tout à fait. Le but du sel est de générer 2 empreintes différentes avec le même mot de passe.

Sur un systeme Unix, le sel est aléatoire et est souvent fonction du pid du process, de la date et d'autres choses encore.

2 personnes disposant du même mot de passe ("123456") auront des empreintes de mot de passe différentes car le sel utilisé sera (très probablement) différent.

[deadalnix]

ctxnop > je comprend ton point.*Pour des choses très simples comme celles que tu cites, ça fonctionne.

mais attention, car cela peut induire des failles. Par exemple, dans le cas du WEP, aucune des fonctions de crytpage mise en œuvre n'est cassée. C'est la façon dont elles sont utilisées qui l'est.

[kaymak]

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.

[deadalnix]

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.

[Inazo]

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 :

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 :

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

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,

[Inazo]

Pas de soucis ^^

[deadalnix]

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

Et de deux spécialistes en carton. DEUX !

Une fonction de hachage, c'est pas bijectif. Et tu peux être sur qu'il y en a un paquet de chaines plus courtes qui ont le même hash. D'autant que MD5 => 32 caractères, c'est juste la façon dont c'est usuellement représenté. Mais ce n'est rien de plus que la représentation d'un nombre en hexadécimal.

[smyley]

Une fonction de hachage, c'est pas bijectif. Et tu peux être sur qu'il y en a un paquet de chaines plus courtes qui ont le même hash.

Sauf qu'en informatique on ne travaille pas sur des infinis. Tu as un hash et sur le site c'est écris en gros de saisir un mot de passe entre 6 et 12 caractères par exemple ... tu va pas aller te mettre à imaginer l'infinité des collisions théoriques possibles pour la même clef.

Après, l'histoire des hash ne reste qu'une partie des faces par lesquelles ont peut attaquer un serveur. C'est pas comme si on pouvais attaquer n'importe quel serveur en testant 700 000 000 mots de passe à la seconde sur celui ci...

[kaymak]

@kaymak:
Ça c'est peut-être ta façon de faire, ce n'est pas celle que j'ai expliqué. Je n'ai pas parlé de sel variant par user et/ou dans le temps. Et si tu fais ainsi, il faudra bien que tu conserve le sel utilisé si tu veux t'assurer que le mot de passe fournit en login est bien le même que celui enregistré en base. Donc retour à la case départ.
Quand à bcrypt, il y a une fonction php fournie avec l'installation par défaut, présente depuis un sacré paquet d'années. Mais encore une fois, c'est du chiffrement, pas du hashage, ca peut paraître semblable, mais les applications en sont totalement différentes. Le chiffrement c'est quand on veux protéger une donner dont la valeur d'origine à une réelle importance. Alors que le hash sert de contrôle uniquement, la valeur d'origine n'a aucune importance. On s'en sert par exemple après un téléchargement, si hash est le même qu'indiqué sur le site du téléchargement, c'est qu'il n'y a pas eu de corruption pendant le transfert. Mais si les hash diffèrent, alors le hash ne te sera absolument d'aucune aide pour trouver ce qui à été corrompu et encore moins pour réparer.

OK, j'ai bien vu le petit oubli de ma part. Méthode intelligente ; ) Et efficace si l'attaquant recherche l'exhaustivité plutôt qu'une information particulière.

pour Bcrypt je n'avais pas percuté plutôt que c'était du cryptage (malgrè le nom de l'algo.... lol), j'avais fais confiance à la newz les yeux fermés.

@Katleen, !!!!

[sovitec]

Whaou, que d'âneries dites sur ce fil.

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

Blowfish est loin d'être un algorithme (avec un i) inconnu. Et la plupart des algorithmes réellement utilisés actuellement sont au moins aussi vieux, voir bien plus (RSA a près de 30 ans). Il faut du temps pour que les spécialistes se persuadent de la robustesse d'un chiffrement.

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

Non, si MD5 a effectivement été affaibli il n'existe pas d'attaque pour retrouver un mot de passe à partir de son hash autre que la force brute. L'attaque découverte permet de générer des collisions (deux mots de passe qui ont le même hash) c'est tout.

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

L'inconvénient des sels uniques à l'application est qu'ils permettent de de détecter facilement les comptes utilisant des mots de passe courant (genre "password" ou "123456") car ils auront tous le même hash.

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.

L'article parle de casser des mots de passe de 6 caractères, pour un mot de passe de 32 ça risque d'être très très... très long.
Mais en cryptographie en suppose toujours que l'attaquant connait la méthode utilisée. Il est en fait complètement inutile de "casser" le premier MD5. Il suffit de passer deux fois l'algorithme MD5 sur le mot de passe et voir si les hash correspondent. C'est un peu plus lent qu'un MD5 simple (à voir s'il n'existe pas des optimisations possibles), mais en fait on se retrouve avec le principe décrit dans l'article, avoir un hash lent à calculer pour ralentir l'attaque, sauf que là l'attaque est encore largement faisable (sur des mots de passe courts).

Plus on s'enferme à tous faire exactement la même chose parce que "c'est la sécurité d'aujourd'hui" et plus la sécurité deviens faible car ca amène plus de monde à travailler à la casser, et le jour où il y arrivent, tout ceux qui ont utilisé cette sécurité seront exposé. Des standards de hash/chiffrement sont indispensables, mais chaque développeur devrait créer son propre petit puzzle pour les stocker, dans l'unique but d'empêcher les bots de fonctionner et donc de faire perdre énormément de temps aux attaquant. Le petit casse tête n'a pas vocation à servir de protection contre l'attaque, ca sert juste à casser l'artillerie lourde de l'attaquant. Parce que prendre d'assaut une forteresse à l'aide de catapulte et autre trébuchet, sans problème, mais y aller à pied avec sa petite épée, ben c'est pas la même chose...

L'expérience montre que c'est une très mauvaise idée, car vouloir faire un système sécurisé sans être spécialiste conduit souvent à des désillusions (voir l'exemple du WEP par exemple, alors on peut imaginer ce que cela donne pour un simple développeur de sites Web).

Des pirates se sont amusés a construire un cluster de 200 PS3 et ont tombé SSL... Source:

Code :

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

http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/

Donc je pense pas que l'algo BCrypt servent a quelque chose :p

On a pensé à ce genre d'attaque depuis que la faiblesse sur MD5 a été dévoilée, Mais elle n'est pas utilisable pour retrouver des mots de passe à partir de leur MD5.

[ctxnop]

L'article parle de casser des mots de passe de 6 caractères, pour un mot de passe de 32 ça risque d'être très très... très long.
Mais en cryptographie en suppose toujours que l'attaquant connait la méthode utilisée. Il est en fait complètement inutile de "casser" le premier MD5. Il suffit de passer deux fois l'algorithme MD5 sur le mot de passe et voir si les hash correspondent. C'est un peu plus lent qu'un MD5 simple (à voir s'il n'existe pas des optimisations possibles), mais en fait on se retrouve avec le principe décrit dans l'article, avoir un hash lent à calculer pour ralentir l'attaque, sauf que là l'attaque est encore largement faisable (sur des mots de passe courts).

Donc ca reviens exactement à ce qu'on disait: ca ne ralenti pas ou très peu.

L'expérience montre que c'est une très mauvaise idée, car vouloir faire un système sécurisé sans être spécialiste conduit souvent à des désillusions (voir l'exemple du WEP par exemple, alors on peut imaginer ce que cela donne pour un simple développeur de sites Web).

Va falloir que je ré-explique combien de fois ? Il n'est nullement question de se prendre pour un spécialiste et d'inventer des algo mathématique ultra complexes de protections qui deviendraient des standards que tout le monde utiliserait après. Je parle juste d'utiliser une sécurité existante et fiable au possible, comme tout le monde, mais en plus d'en personnaliser le stockage via un petit puzzle pas bien complexe mais le plus trompeur possible. Comme par exemple, faire croire à l'utilisation d'un algo alors qu'on en utilise un autre. C'est tout con, ca ne met pas en danger la fiabilité de l'algo utilisé puisqu'il reste totalement intacte, et ca casse le fonctionnement des bots qui ne sont pas prévu pour l'utilisation d'une telle fourberie. C'est tout, ca ne va pas plus loin, ce n'est pas se prendre pour un spécialiste, ni réinventer la roue ou un algo ultra complexe.
Tu cites le WEP comme exemple, mais le WEP n'est justement pas personnalisé, c'est le même algo pour tout ceux qui l'utilisent, alors forcément des outils ont été fait pour le casser et aujourd'hui c'est un jeu d'enfant de le faire tomber.
A contrario, moi je cite l'exemple des captcha "stupides" qu'on commence à voir fleurir et qui sont finalement aussi efficaces si ce n'est plus que les solutions complexes type reCaptcha. La raison est simple, les bots ont été créés pour faire tomber les générateurs d'images, pas pour répondre à des question stupides. J'ai vu un site (je ne sais plus lequel malheureusement) où le webmaster avait comme captcha "combien font un plus un ?". C'est tout, ca ne varie jamais, toujours la même question. Et pourtant il dit que ca arrête la quasi totalité des spams. Parce qu'aucun bot n'est fait pour contrer son test et ce notamment parce que personne n'utilise le même test que lui. Le jour où un bot sera fait pour sa question, il n'aura qu'a changer de question.
Cette petite personnalisation de rien du tout est suffisante pour casser les outils de masse, et quand on casse un outil de masse on fait perdre énormément de temps à l'attaquant. Mais jamais il n'a été question dans mes propos que ca remplace une sécurité standardisée, connue, fiable, ..., c'est complémentaire uniquement.