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

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 je choisis un schéma de hachage de mot de passe? BCrypt est-il une «bonne» implémentation?

Tout d'abord, quelques termes importants:

Hashing - Action de prendre une chaîne et de produire une séquence de caractères qui ne peut pas être rétablie dans la chaîne d'origine.

Cryptage symétrique - (généralement simplement appelé `` cryptage '') - Action de prendre une chaîne et de produire une séquence de caractères pouvant être déchiffrée dans la chaîne d'origine grâce à l'utilisation de la même clé de cryptage qui l'a cryptée.

Rainbow Table - une table de recherche qui contient toutes les variations de caractères hachés dans un algorithme de hachage spécifique.

Salt - une chaîne aléatoire connue ajoutée à la chaîne d'origine avant qu'elle ne soit 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 existe de graves défauts 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 prévoyez de mettre en œuvre votre propre sécurité par mot de passe (soupir), vous devez faire plusieurs choses:

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

Malheureusement, même si vous faites tout cela, un pirate informatique déterminé pourrait toujours trouver les mots de passe, cela lui prendrait vraiment beaucoup de temps. C'est votre principal ennemi: le temps .

L' algorithme bcrypt fonctionne car il faut cinq ordres de grandeur de plus pour hacher un mot de passe que MD5 ; (et toujours 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 rend beaucoup moins probable que vos mots de passe soient en danger d'être piratés.

Si vous salez et hachez vos mots de passe et que chaque sel est différent, alors un pirate 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 hacker doit générer 1 million de tables arc-en-ciel. Si vous utilisez le même sel pour chaque utilisateur, le pirate n'a qu'à générer 1 table arc-en-ciel pour pirater votre système avec succès.

Si vous ne saluez pas vos mots de passe, tout ce qu'un attaquant a à faire est de récupérer une table Rainbow existante pour chaque implémentation (AES, SHA-512, MD5) et de voir si l'une correspond au hachage. Cela a déjà été fait , un attaquant n'a pas besoin de calculer lui-même ces tables Rainbow .

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, et. Al. ) Sur votre site, une bonne sécurité par mot de passe n'a pas d'importance. Cela ressemble à une déclaration controversée, mais pensez-y: si je peux obtenir toutes vos informations utilisateur via une attaque par injection SQL, ou si je peux amener vos utilisateurs à me donner leurs cookies via XSS, peu importe la qualité de votre mot de passe la sécurité est .

Autres ressources:

1. Jeff Atwood: .NET Encryption Simplified (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 les mots de passe de manière incorrecte
4. Jeff Atwood: Speed ​​Hashing

Remarque: veuillez recommander d'autres bonnes ressources. J'ai dû lire une douzaine d'articles rédigés par des dizaines d'auteurs, mais peu écrivent aussi clairement sur le sujet que Jeff. Veuillez modifier les articles au fur et à mesure que vous les trouvez.

Vous ne devez pas utiliser BCrypt dans .NET. Vous devez utiliser PBKDF2 tel quel avec l'implémentation du framework .NET intégrée. C'est la seule implémentation vérifiée cryptographiquement disponible gratuitement dans .NET en plus d'être l' algorithme recommandé par le NIST .

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

Pour les curieux, nous hachons les mots de passe avec PBKDF2. Le code Relavent est ici ( 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 utilisions BCrypt; mais déplacé vers PBKDF2 car il est intégré au framework .NET, alors que BCrypt nous obligerait à vérifier une implémentation (pas une petite entreprise).

Kevin Montrose, 27 mai 2011

(Lien mis à jour sur GitHub)

Edit: La signification de vérifié en termes cryptographiques ne semble pas être facilement comprise, une implémentation vérifiée signifie qu'il a été prouvé cryptographiquement d'être implémenté sans erreur. Le coût peut facilement atteindre 20 000 $ ou plus. Je me souviens de cela lorsque je faisais des recherches sur OpenSSL et lisais où ils déclaraient qu'ils n'avaient pas terminé tout le processus de vérification, mais si vous avez besoin de vérifier qu'ils peuvent vous indiquer la bonne voie et mentionner les coûts associés. Certaines exigences gouvernementales incluent des mandats pour des algorithmes de cryptage 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 a pas de fautes malveillantes intentionnelles, telles que l'autorisation d'une porte dérobée dans ce qui est chiffré ou des erreurs d'implémentation involontaires qui entraînent des données cryptographiquement non sécurisées.

Édition 2014: Pour quiconque remet en question l'impérativité de l'utilisation d'algorithmes cryptopgraphiques vérifiés, examinez la dévastation provoquée par le piratage de cœur 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 découvriez que n'importe qui 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 "n'avait pas validé une variable contenant une longueur" et a nié toute intention de soumettre une implémentation défectueuse. Suite à la divulgation de Heartbleed, Seggelmann a suggéré de se concentrer sur le deuxième aspect, déclarant qu'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 toute la sécurité.

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