J’ai lu que lors du hachage d’un mot de passe, de nombreux programmeurs recommandent d’utiliser l’algorithme BCrypt.
Je programme en C # et je me demande si quelqu’un connaît une bonne implémentation pour BCrypt? J’ai trouvé cette page , mais je ne sais pas vraiment si c’est faux ou pas.
Que dois-je savoir lorsque vous choisissez un schéma de hachage de mot de passe? BCrypt est-il une «bonne» implémentation?
Premièrement, certains termes importants:
Hachage – Le fait de prendre une chaîne et de produire une séquence de caractères qui ne peut pas être retournée à la chaîne d’origine.
Cryptage symésortingque – (Généralement appelé «cryptage») – Action consistant à prendre une chaîne de caractères et à produire une séquence de caractères pouvant être décryptée dans la chaîne d’origine grâce à la même clé de cryptage.
Rainbow Table – Table de consultation contenant toutes les variations de caractères hachées dans un algorithme de hachage spécifique.
Salt – une chaîne aléatoire connue ajoutée à la chaîne d’origine avant d’être hachée.
Pour le .NET Framework, Bcrypt n’a pas encore d’implémentation de référence vérifiée . Ceci est important car il n’y a aucun moyen de savoir s’il y a des failles graves dans une implémentation existante. Vous pouvez obtenir une implémentation de BCrypt pour .NET ici . Je ne connais pas assez la cryptographie pour dire si c’est une bonne ou une mauvaise implémentation. La cryptographie est un domaine très profond. Ne tentez pas de créer votre propre algorithme de chiffrement . Sérieusement.
Si vous souhaitez implémenter votre propre sécurité par mot de passe (soupir), vous devez faire plusieurs choses:
Malheureusement, même si vous faites tout cela, un pirate informatique déterminé pourrait encore trouver les mots de passe, cela lui prendrait très longtemps. C’est ton ennemi principal: le temps .
L’ algorithme bcrypt fonctionne parce qu’il faut cinq ordres de grandeur de plus pour hacher un mot de passe que MD5 ; (et encore beaucoup plus long que AES ou SHA-512). Cela oblige le pirate à passer beaucoup plus de temps à créer une table arc-en-ciel pour rechercher vos mots de passe, ce qui réduit considérablement la probabilité que vos mots de passe soient piratés.
Si vous salez et hachez vos mots de passe, et que chaque sel est différent, un pirate potentiel devra créer une table arc-en-ciel pour chaque variante de sel , simplement pour avoir une table arc-en-ciel pour un mot de passe salé. Cela signifie que si vous avez 1 million d’utilisateurs, un pirate informatique doit générer 1 million de tables arc-en-ciel. Si vous utilisez le même sel pour chaque utilisateur, le pirate doit uniquement générer 1 table arc-en-ciel pour pirater votre système.
Si vous ne saluez pas vos mots de passe, tout ce qu’un attaquant a à faire est de créer une table Rainbow existante pour chaque implémentation (AES, SHA-512, MD5) et de voir si l’une correspond à la table de hachage. Cela a déjà été fait , un attaquant n’a pas besoin de calculer ces tables Rainbow elles-mêmes .
Même avec tout cela, vous devez utiliser de bonnes pratiques de sécurité . S’ils peuvent utiliser avec succès un autre vecteur d’attaque (XSS, SQL Injection, CSRF, etc. ) sur votre site, la sécurité d’un mot de passe est sans importance. Cela ressemble à une déclaration controversée, mais réfléchissez-y: si je peux obtenir toutes vos informations utilisateur lors d’une attaque par injection SQL, ou si mes utilisateurs peuvent me fournir leurs cookies via XSS, le niveau de votre mot de passe importe peu la sécurité est .
Autres ressources:
Note: S’il vous plaît recommander d’autres bonnes ressources. J’ai dû lire une douzaine d’articles par des dizaines d’auteurs, mais peu écrivent aussi clairement que Jeff. S’il vous plaît éditer dans les articles que vous les trouvez.
Vous ne devez pas utiliser BCrypt dans .NET. Vous devez utiliser PBKDF2 comme c’est le cas avec l’implémentation du framework .NET intégrée. C’est la seule implémentation librement vérifiable cryptographiquement disponible dans .NET, en plus d’être l’ algorithme recommandé par le NIST .
StackId utilisait précédemment BCrypt et déplacé vers PBKDF2 pour cette raison même:
Pour les curieux, nous hachons les mots de passe avec PBKDF2. Le code correct est ici ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), via quelques couches d’indirection. Dans une itération antérieure, nous utilisions BCrypt; mais déplacé à PBKDF2 comme il est intégré dans le framework .NET, alors que BCrypt nous obligerait à vérifier une implémentation (pas de petite entreprise).
Kevin Montrose, le 27 mai 2011
(Lien mis à jour sur GitHub)
Edit: La signification de vérifiée en termes cryptographiques ne semble pas être facile à comprendre, une implémentation vérifiée signifie qu’elle a été prouvée cryptographiquement pour être implémentée sans erreur. Le coût peut facilement atteindre 20 000 $ ou plus. Je m’en souviens lorsque je faisais des recherches sur OpenSSL et lisais où ils affirmaient ne pas avoir terminé le processus de vérification complet, mais si vous avez besoin de vérifier qu’ils peuvent vous indiquer la voie à suivre et les coûts associés. Certaines exigences gouvernementales incluent des mandats pour des algorithmes de chiffrement vérifiés.
Les implémentations bcrypt dans .NET n’ont pas été vérifiées. En utilisant une implémentation de chiffrement non vérifiée, vous ne pouvez pas être absolument certain qu’il n’y a pas de fautes malveillantes intentionnelles, comme autoriser une porte dérobée dans ce qui est crypté ou des fautes d’implémentation involontaires qui entraînent des données non sécurisées.
2014 edit: Pour quiconque a mis en doute le caractère impératif de l’utilisation d’algorithmes cryptopgraphiques vérifiés, examinez la dévastation causée par le hackeded exploité par OpenSSL. C’est le coût de l’utilisation d’une implémentation non vérifiée. C’est sécurisé … jusqu’à ce que vous découvriez qu’une personne peut lire tout le contenu de la mémoire de votre serveur.
L’auteur du changement qui a introduit Heartbleed, Robin Seggelmann, a déclaré qu’il “manquait de valider une variable contenant une longueur” et a nié toute intention de soumettre une implémentation erronée. Suite à la divulgation de Heartbleed, Seggelmann a suggéré de se concentrer sur le deuxième aspect, en déclarant que OpenSSL n’est pas examiné par suffisamment de personnes.
C’est la définition d’une implémentation non vérifiée. Même le plus petit défaut peut entraîner la paralysie de la sécurité entière.
2015 edit: Suppression du langage basé sur les recommandations et remplacement par des absolus. Commentaire original de Kevin Montrose pour la postérité.