BCrypt est-il un bon algorithme de hachage à utiliser en C #? Où puis-je le trouver? [fermé]

Question

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 est au courant d'une bonne implémentation de BCrypt. J'ai trouvé cette page , mais je ne sais pas vraiment si c'est faux ou pas.

De quoi dois-je avoir connaissance lors du choix d’un schéma de hachage de mot de passe? BCrypt est-il une "bonne" implémentation?

Answer 1

Premièrement, quelques termes importants:

Hashing - Le fait de prendre une chaîne et de produire un séquence de caractères ne pouvant pas revenir à la chaîne d'origine.

Cryptage symétrique - (généralement simplement appelé "cryptage symétrique") 'chiffrement'): acte consistant à prendre une chaîne et à générer une séquence de caractères que peut être déchiffré en chaîne originale en utilisant la même clé de chiffrement que celle qui l'a chiffrée.

Table arc-en-ciel - une table de recherche contenant toutes les variantes de caractères hachés dans un algorithme de hachage spécifique.

Salt - une chaîne aléatoire connue a été ajoutée. à la chaîne d'origine avant son hachage.

Pour le .NET Framework, Bcrypt n'a pas encore d'implémentation de référence vérifiée . Ceci est important car il est impossible de savoir s'il existe de graves lacunes 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. N'essayez pas de créer votre propre algorithme de chiffrement . Sérieusement.

Si vous souhaitez mettre en place votre propre sécurité par mot de passe (soupir), vous devez alors effectuer plusieurs opérations:

1. Utilisez un algorithme de hachage relativement sécurisé .
2. Salez chaque mot de passe avant qu'il ne soit haché.
3. Utilisez un unique et long sel pour chaque mot de passe et stockez le sel avec le mot de passe.
4. Exigez des mots de passe forts .

Malheureusement, même si vous faites tout cela, un pirate informatique déterminé pourrait tout de même déterminer les mots de passe, cela ne lui prendrait que très longtemps. C'est votre principal ennemi: Le temps .

L’algorithme bcrypt fonctionne car il nécessite cinq des ordres de grandeur plus longs pour hacher un mot de passe que MD5 ; (et toujours beaucoup plus long que AES ou SHA-512). Cela oblige le pirate informatique à passer plus de temps à créer une table arc-en-ciel pour la recherche de vos mots de passe, ce qui réduit considérablement les risques de piratage de vos mots de passe.

Si vous salez et hachez vos mots de passe et que chaque sel est différent, alors un pirate informatique potentiel devrait créer une table arc-en-ciel pour chaque variante de sel , juste pour avoir une table arc-en-ciel pour un mot de passe salé + haché. 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 tous les utilisateurs, le pirate informatique ne doit générer qu'un seul tableau arc-en-ciel pour pouvoir pirater votre système.

Si vous ne salez pas vos mots de passe, il suffit alors à un attaquant d'extraire une table Rainbow existante pour chaque implémentation (AES, SHA-512, MD5) et de voir si celle-ci correspond au hachage. Cette a déjà été effectuée , 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, Injection SQL, CSRF, et. al. ) sur votre site, une bonne sécurité des mots de passe importe peu. Cela ressemble à une déclaration controversée, mais réfléchissez-y: Si je peux obtenir toutes vos informations utilisateur par le biais d'une attaque par injection SQL ou si vos utilisateurs me donnent leurs cookies par XSS, La sécurité de votre mot de passe est donc sans importance .

Autres ressources:

1. Jeff Atwood: . Cryptage .NET simplifié (idéal pour un aperçu du hachage)
2. Jeff Atwood: Je viens de me connecter en tant que vous
3. Jeff Atwood: Vous stockez probablement mots de passe incorrects
4. Jeff Atwood: Hashing rapide

Remarque: recommandez d’autres ressources intéressantes. J'ai dû lire une douzaine d'articles rédigés par des dizaines d'auteurs, mais rares sont ceux qui écrivent aussi clairement sur le sujet que Jeff. Veuillez modifier les articles au fur et à mesure que vous les trouvez.

Answer 2

Vous ne devez pas utiliser BCrypt dans .NET. Vous devez utiliser PBKDF2 tel quel avec l'implémentation du framework .NET intégré. Il s’agit de la seule implémentation vérifiée cryptographiquement librement disponible dans .NET, avec la . algorithme recommandé par le NIST .

StackId utilisait auparavant BCrypt et a été déplacé vers PBKDF2 pour cette raison même:

  

Pour les curieux, nous & # 8217; hachaînons les mots de passe avec PBKDF2. Code fiable   est là (    http://code.google.com/p/ stackid / source / browse / OpenIdProvider / Current.cs # 1135   ), à travers quelques couches d'indirection. Dans une itération précédente, nous   utilisaient BCrypt; mais déplacé vers PBKDF2 car il est intégré dans le .NET   cadre, alors que BCrypt exigerait de nous de vérifier une mise en œuvre   (pas de petite entreprise).

Kevin Montrose, le 27 mai 2011 .

(lien mis à jour sur GitHub)

Modifier: Le sens de vérifié en termes cryptographiques ne semble pas être facilement compris, une implémentation vérifiée signifie que son implémentation a été prouvée cryptographiquement sans erreur. Le coût de ceci peut facilement atteindre 20 000 $ ou plus. Je me souviens de cela lorsque je faisais des recherches sur OpenSSL et lisais où ils ont déclaré qu’ils n’avaient pas achevé tout le processus de vérification, mais que vous avez besoin de bien vérifier qu’ils peuvent vous indiquer la bonne voie et les coûts associés. Certaines exigences gouvernementales incluent des mandats pour les algorithmes de chiffrement vérifiés.

Les implémentations de 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 aura pas non plus de fautes malveillantes intentionnelles, telles que permettre une porte dérobée vers des erreurs de mise en œuvre chiffrées ou non intentionnelles entraînant des données cryptographiquement non sécurisées.

Modification 2014: Pour tous ceux qui s'interrogent sur l'impératif d'utilisation d'algorithmes cryptographiques vérifiés, regardez la dévastation provoquée par le piratage heartbleed exploité dans OpenSSL. C'est le coût d'utilisation d'une implémentation non vérifiée. C'est sécurisé .... jusqu'à ce que vous sachiez que n'importe qui peut lire le contenu de la mémoire en entier sur votre serveur.

  

L'auteur du changement qui a introduit Heartbleed, Robin Seggelmann, a déclaré qu'il & avait raté la validation d'une variable contenant une longueur &>; et a nié toute intention de soumettre une mise en œuvre erronée. À la suite de la divulgation de Heartbleed, Seggelmann a suggéré de se concentrer sur le deuxième aspect, affirmant qu'OpenSSL n'est pas examiné par suffisamment de personnes.

Ceci est la définition d'une implémentation non vérifiée. Même le plus petit défaut peut compromettre toute la sécurité.

Modification de 2015: Suppression du langage basé sur la recommandation et son remplacement par des absolus. Commentaire original intégré de Kevin Montrose pour la postérité.