Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Katleen Erna

22PARTAGES

0  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Thorna
Membre éprouvé https://www.developpez.com
Le 02/02/2010 à 7:28
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 ?
0  0 
Avatar de rguef
Candidat au Club https://www.developpez.com
Le 02/02/2010 à 9:08
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.
0  0 
Avatar de daredare
Membre du Club https://www.developpez.com
Le 02/02/2010 à 9:17
Citation Envoyé par Thorna Voir le message
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é !
0  0 
Avatar de rguef
Candidat au Club https://www.developpez.com
Le 02/02/2010 à 9:28
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...
0  0 
Avatar de lochnar
Membre du Club https://www.developpez.com
Le 02/02/2010 à 9:30
Citation Envoyé par Thorna Voir le message
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 ^^
0  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 02/02/2010 à 9:34
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 ?
0  0 
Avatar de vanquish
Membre éprouvé https://www.developpez.com
Le 02/02/2010 à 10:31
Citation Envoyé par Marco46 Voir le message
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 ?
0  0 
Avatar de dams78
Membre chevronné https://www.developpez.com
Le 02/02/2010 à 10:59
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...
0  0 
Avatar de kain_tn
Membre émérite https://www.developpez.com
Le 02/02/2010 à 12:04
pourquoi est-ce que le sel est devenu inutile?
0  0 
Avatar de Inazo
Membre confirmé https://www.developpez.com
Le 02/02/2010 à 12:23
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,
0  0