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

129

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?

Svish
la source

Réponses:

148

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.

George Stocker
la source
peut-être ajouter à votre paragraphe sur le sel qu'un sel doit être choisi au hasard
Jacco
2
@Jacco Bon appel, a ajouté. Bien que ce ne soit pas si important. Vous pouvez simplement utiliser l'horodatage de la connexion pour le sel. La différence est que l'attaquant doit ensuite recalculer la table arc-en-ciel pour chaque sel. C'est ce qui rend les choses difficiles, non pas que ce soit choisi au hasard. Le rendre aléatoire ajouterait une autre couche d'obsfucation, mais cela ne sert à rien une fois que l'attaquant est capable de voir votre base de données (ce qui est le problème qui cause tout notre chagrin d'amour en premier lieu).
George Stocker
3
Pas vraiment, le sel n'a pas à être secret, juste unique pour chaque instance. Comme l'unique (comme dans le monde entier) n'est pas possible, le hasard est la meilleure chose à faire. De plus, l' horodatage n'est pas un bon sel car il n'y a pas assez d'entropie.
Jacco
7
Je ne suis pas d'accord avec votre déclaration "S'ils peuvent utiliser avec succès l'injection XSS ou SQL, une bonne sécurité par mot de passe n'a pas d'importance." Au contraire, s'ils parviennent à injecter avec succès XSS ou SQL dans votre site, une bonne sécurité par mot de passe est encore plus importante. La clé ici est la «défense en profondeur» - vous devez renforcer la sécurité autant que possible à chaque couche de votre application.
jammycakes
2
@jammycakes Absolument; mon point a été perdu: vous ne pouvez pas simplement dire, "Hé, nous hachons et salons nos mots de passe," nous allons bien "!
George Stocker
74

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

Chris Marisic
la source
25
Pour citer le commentaire lié: «[nous] sommes passés à PBKDF2 car il est intégré au framework .NET, alors que BCrypt nous obligerait à vérifier une implémentation». Notez que le commentaire ne dit pas que l' algorithme est meilleur, mais que SE Dev Team considère l' implémentation PBKDF2 intégrée plus fiable qu'une bibliothèque externe (qui est, en fin de compte, un appel de jugement).
Piskvor a quitté le bâtiment
3
@Piskvor J'ai mis à jour ma réponse. Il ne s'agit pas de ce que l'équipe SO considère comme sûr, mais d'un jugement entre la sécurité intrinsèquement prouvée ou, espérons-le, la sécurité. Ce dernier en matière de cryptographie est inacceptable.
Chris Marisic
6
Je me demande comment SO a migré tous les mots de passe hachés bcrypt vers les nouveaux hachages? N'auraient-ils pas besoin des mots de passe bruts pour le hacher en utilisant le nouvel algorithme?
Dharmendar Kumar 'DK' le
8
@DK Je ne pense même pas que vous deviez leur demander de réinitialiser leurs mots de passe. Lors de la prochaine connexion (où ils fournissent leur mot de passe en clair), vous pouvez le faire, je crois.
Matt Kocaj
12
C'est un mauvais conseil et je suis surpris qu'il y ait autant de votes positifs. Vérifier une implémentation de BCrypt dans un langage géré est beaucoup, beaucoup plus trivial que de vérifier quelque chose comme une implémentation SSL entière dans C. Heartbleed est complètement hors de propos; vous feriez mieux de mentionner quelque chose comme les problèmes de contrainte de type PHP avec les contrôles d'égalité de hachage. De plus, bien que largement approprié dans un sens pratique, PBKDF2 est un KDF, pas un algorithme de hachage de mot de passe, alors que BCrypt est mieux adapté. Quoi qu'il en soit, il serait beaucoup plus logique d'utiliser Argon2 ces jours-ci de toute façon, pour lequel il existe une bibliothèque C # bien testée
Polynomial