Ist BCrypt ein guter Hashing-Algorithmus in C # verwenden? Wo kann ich es finden? [geschlossen]

Question

Ich habe gelesen, dass, wenn ein Kennwort-Hashing, viele Programmierer empfehlen BCrypt Algorithmus.

Ich programmiere in C # und mich gefragt, ob jemand eine gute Implementierung für BCrypt weiß? Ich fand diese , aber ich weiß nicht wirklich, wenn es fehlerhaft ist oder nicht.

Was muss ich beachten, wenn ein Kennwort-Hashing-Schema der Wahl? Ist bcrypt eine 'gute' Umsetzung?

Answer 1

Zunächst einige Begriffe, die wichtig sind:

Hashing - Der Akt der eine Schnur nehmen und produzieren ein Folge von Zeichen, die. nicht auf die ursprüngliche Zeichenfolge rückgängig gemacht werden

Symmetrische Verschlüsselung - (In der Regel bezeichnet nur als ‚Verschlüsselung‘.) - der Akt der eine Zeichenfolge zu nehmen und eine Folge von Zeichen erzeugen, die können auf die ursprüngliche Zeichenfolge durch die Verwendung des gleichen Verschlüsselungsschlüssel entschlüsselt werden, die es verschlüsselt

Rainbow Table - eine Lookup-Tabelle, die alle Variationen enthält von Zeichen in einem bestimmten Hash-Algorithmus gehasht.

Salz - eine bekannte zufällige Zeichenfolge angehängt auf den String original bevor es gehasht.

Für das .NET Framework, hat Bcrypt noch nicht haben eine verifiziert Referenzimplementierung. Dies ist wichtig, weil es keine Möglichkeit zu wissen, ob es gravierende Mängel in einer bestehenden Implementierung. Sie können eine Implementierung von BCrypt für .NET hier bekommen. Ich weiß nicht genug über Kryptographie zu sagen, ob es eine gute oder schlechte Umsetzung ist. Kryptographie ist ein sehr tiefes Feld. Versuchen Sie nicht, Ihren eigenen Verschlüsselungsalgorithmus zu bauen. Ernsthaft.

Wenn Sie vorhaben, Ihre eigene Passwort-Sicherheit (seufz) implementieren, dann müssen Sie mehrere Dinge tun:

1. Verwenden Sie einen rel="noreferrer">.
2. Salz jedes Passwort, bevor es gehasht.
3. Verwenden Sie eine einzigartiges und lang Salz für jedes Passwort , und speichern Sie das Salz mit der Kennwort ein.
4. erfordern starke Passwörter .

Leider, auch wenn Sie dies alles tun, könnte ein entschlossener Hacker nach wie vor potentiell die Passwörter herauszufinden, es würde ihn nur nehmen eine wirklich lange Zeit. Das ist Ihr Hauptfeind. Zeit

Die bcrypt Algorithmus funktioniert, weil es dauert fünf Größenordnung länger ein Passwort als MD5 Hash; (Und immer noch viel länger als AES oder SHA-512). Es zwingt den Hacker viel mehr Zeit damit verbringen, eine Regenbogen-Tabelle erstellen Sie Ihre Passwörter nachzuschlagen, so dass es weit weniger wahrscheinlich, dass Ihre Kennwörter in Gefahr von gehackt werden.

Wenn Sie das Salzen und Ihre Passwörter Hashing und jedes Salz ist anders, dann ein potentieller Hacker müßte eine Regenbogen-Tabelle für jede Variation von Salz schaffen, nur eine Regenbogen-Tabelle für ein gesalzenes + gehasht Passwort. Das heißt, wenn Sie eine Million Benutzer haben, ein Hacker generieren 1000000 Rainbow Tables hat. Wenn Sie das gleiche Salz verwenden für jeden Benutzer, dann nur der Hacker hat 1 Rainbow-Tabelle zu erzeugen, um Ihr System erfolgreich zu hacken.

Wenn Sie nicht Ihre Passwörter salzen, dann sind alle ein Angreifer zu tun hat, ist ein bestehendes Rainbow-Tables für jede Implementierung zu, da draußen (AES, SHA-512, MD5) und nur zu sehen, wenn man den Hash übereinstimmt. Diese bereits getan wurde, kann ein Angreifer nicht diese Rainbow Tables selbst berechnen müssen .

Selbst mit all dies, Sie haben gute Sicherheitspraktiken zu verwenden Wenn sie erfolgreich einen weiteren Angriffsvektor (XSS, SQL Injection, CSRF, et al ) auf Ihrer Website, gute Passwort-Sicherheit spielt keine Rolle, das klingt wie eine umstrittene Aussage, aber denken sie daran: wenn ich alle Ihre Benutzerinformationen über einen SQL-Injection-Angriff bekommen, oder ich kann Ihren Benutzer zu erhalten, um mir ihre Cookies durch XSS, dann ist es egal, wie gut Ihr Passwort-Sicherheit ist .

Weitere Informationen:

1. Jeff Atwood: .NET Encryption Vereinfachtes (ideal für einen Überblick über Hashing)
2. Jeff Atwood: ich loggte nur in, wie Sie
3. Jeff Atwood: Du bist wahrscheinlich zu speichern Passwörter falsch
4. Jeff Atwood: Geschwindigkeit Hashing

Hinweis: Bitte andere gute Ressourcen empfehlen. Ich habe muß ein Dutzend Artikel von Dutzenden von Autoren lesen, aber nur wenige schreiben so klar zu dem Thema, wie Jeff tut. Bitte bearbeiten in Artikeln, wie Sie sie finden.

Answer 2

Sie muss nicht BCrypt in .NET verwenden. Sie muss PBKDF2 verwenden wie bei der in .NET Framework-Implementierung aufgebaut ist. Es ist das einzige frei verfügbare kryptographisch verifiziert Implementierung in .NET zusammen mit Sein der Algorithmus, der von NIST empfohlen.

StackId bisher verwendete BCrypt und zog nach PBKDF2 aus diesem Grunde:

  

Für diejenigen neugierig, sind Hashing wir Passwörter mit PBKDF2. relavent Code   ist hier (    http://code.google.com/p/ stackid / source / browse / OpenIdProvider / Current.cs # 1135   ), Durch ein paar Schichten von Indirektion. In einer früheren Iteration wir   mit BCrypt waren; zog aber nach PBKDF2 wie es in .NET gebaut   Rahmen, während BCrypt müssten wir eine Implementierung überprüfen   (Kein kleines Unternehmen).

Kevin Montrose, 27. Mai 2011

(Aktualisiert Link auf GitHub)

Edit: Die Bedeutung von verifiziert in kryptographischen Begriffen scheint nicht leicht zu verstehen ist, ein bestätigtes Implementierung bedeutet es bewiesen ist schon kryptografisch fehlerfrei umgesetzt werden. Die Kosten hierfür können $ 20.000 oder höher leicht erreichen. Ich erinnere mich, als ich wurde Forschung auf OpenSSL tun und lesen, wo sie erklärten, sie haben nicht den gesamten Prüfungsprozess erfolgreich abgeschlossen, aber wenn Sie in vollem Umfang überprüft müssen, dass sie Sie zeigen den richtigen Weg für sie nach unten und erwähnt Kosten verbunden. Bestimmte staatliche Auflagen umfassen Mandate für geeichte Verschlüsselungsalgorithmen.

Die bcrypt Implementierungen in .NET noch nicht überprüft worden. Mit Hilfe eines nicht verifizierten Implementierung Verschlüsselung Sie können nicht absolut sicher sein, dass es auch nicht absichtlich schädliche Störungen ist es wie eine Backdoor in ermöglicht, was verschlüsselt ist oder unbeabsichtigte Implementierung Fehler, die in kryptografisch unsicheren Daten führen.

2014 edit: Für alle, die den Imperativ in Frage gestellt von cryptopgraphical algorithims an der Verwüstung sehen mit prüft, die von der Heartbleed Hack in OpenSSL genutzt. Das sind die Kosten für einen nicht verifizierten Implementierung verwenden. Es ist sicher ...., bis Sie, dass jede Person nur herausfinden kann, den gesamten Speicherinhalt des Servers lesen.

  

Der Autor der Änderung, die Heartbleed, Robin Seggelmann eingeführt, erklärte, dass er „verpasst eine Variable Validieren einer Länge enthält“ und verweigert jegliche Absicht eine fehlerhafte Umsetzung vorzulegen. Heartbleed der Offenbarung Nach schlug Seggelmann auf dem zweiten Aspekt konzentriert, die besagt, dass OpenSSL nicht von genügend Menschen überprüft.

Dies ist die Definition von einer nicht bestätigten Umsetzung. Selbst der kleinste Fehler in Folge die gesamte Sicherheit lähmen.

2015 bearbeiten: Entfernte Empfehlung basierte Sprache und mit Absoluten ersetzt. Embedded original Kevin Montrose Kommentar für die Nachwelt.