Frage an salt, bcrypt, passwords, hash, encryption – Web-App-Passwörter: bcrypt und SHA256 (und scrypt)

13

Bei all den jüngsten (z. B. LinkedIn) Diskussionen über Passwörter habe ich mich mit Implementierungen von Passwort-Hashing befasst. Nach zwei Tassen Kaffee und einer morgendlichen Lektüre bin ich kein Kryptograf mehr als zu Beginn. Und ich möchte wirklich nicht so tun, als wäre ich es.

Spezifische Fragen

Schlägt die Verwendung einer ganzzahligen eindeutigen Benutzer-ID als effektives Salt fehl? (crypt () verwendet nur 16 Bits?)

Wenn ich sha256 () für einen Hash einfach immer wieder ausführe, bis eine Sekunde vergangen ist, sind dann die Brute-Force-Angriffe besiegt?

Wenn ich diese Fragen stellen muss, sollte ich bcrypt verwenden?

Diskussion / Erklärung:

Das Ziel ist einfach, wenn die gehashten Passwörter meiner Benutzer durchgesickert sind:

wäre nicht "leicht" zu knacken,Das Knacken eines Kennworts würde andere Benutzer, die dasselbe Kennwort verwenden, nicht aussetzen.

Was ich für # 1 gelesen habe, ist, dass die Hash-Berechnung teuer sein muss - beispielsweise ein oder zwei Sekunden, um sie zu berechnen, und möglicherweise ein bisschen oder Speicher (um die Hardware-Entschlüsselung zu vereiteln).

bcrypt hat dies eingebaut und scrypt ist, wenn ich das richtig verstehe, zukunftssicherer und beinhaltet eine minimale Speicheranforderung.

Aber ist es ein ebenso effektiver Ansatz, die Zeit zu essen, indem das Ergebnis von sha256 () so oft "nachgewärmt" wird, bis einige Sekunden vergangen sind, und dann die endgültige Schleifenzahl mit dem Hash gespeichert wird, um später ein angegebenes Passwort zu überprüfen?

Für # 2 ist es wichtig, ein eindeutiges Salt für jedes Passwort zu verwenden. Was nicht klar war, ist, wie zufällig (oder groß) das Salz sein muss. Wenn das Ziel ist, zu vermeiden, dass jeder, der "mypassword" als Passwort verwendet, denselben Hash hat, ist es nicht genug, dies einfach zu tun ?:

hash = sha256_hex( unique_user_id + user_supplied_password );

oder auch das, obwohl ich nicht sicher bin, ob es mir etwas kauft:

hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );

Der einzige Vorteil, den ich aus der Verwendung der Benutzer-ID ziehen kann, ist, dass ich nicht das Salz zusammen mit dem Hash speichern muss. Kein großer Vorteil. Gibt es ein echtes Problem bei der Verwendung einer Benutzer-ID als Salt? Schafft es nicht # 2?

Ich gehe davon aus, dass jemand, der die Hash-Passwörter meines Benutzers stehlen kann, alles bekommen kann, was er will - einschließlich des Quellcodes, der den Hash generiert. Gibt es also einen Vorteil, wenn Sie dem Kennwort vor dem Hashing eine zusätzliche zufällige Zeichenfolge (dieselbe Zeichenfolge) hinzufügen? Das ist:

# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );

Ich habe den Vorschlag gesehen, aber ich verstehe nicht, was ich davon über das Salz pro Benutzer gewinne. Wenn jemand den Angriff brachial erzwingen wollte, würde er diesen "app_wide_string" kennen und diesen beim Ausführen seines Wörterbuchangriffs verwenden, oder?

Gibt es einen guten Grund, bcrypt anstelle des oben beschriebenen Rollens zu verwenden? Vielleicht ist die Tatsache, dass ich diese Fragen stelle, Grund genug?

Übrigens: Ich habe gerade eine vorhandene Hashing-Funktion zeitlich festgelegt, die ich auf meinem Laptop habe, und ich kann ungefähr 7000 Hashes pro Sekunde generieren. Nicht ganz die ein oder zwei Sekunden, die oft vorgeschlagen werden.

Einige verwandte Links:

Verwenden von sha256 als Hashing und Salting mit der Benutzer-ID

SHA512 gegen Blowfish und Bcrypt

Was ist die optimale Länge für das Benutzerkennwort salt?

Deine Antwort

2   die antwort
0

wirksames Salt fehl? (crypt () verwendet nur 16 Bits?)

Normalerweise verwenden Sie ein zufällig generiertes Salt und speichern diesen Hash zusammen mit dem verschlüsselten Passwort. Es spielt keine Rolle, dass der Angreifer auch Zugriff auf das Salt erhält - der Zweck besteht darin, die Verwendung einer Nachschlagetabelle zu verhindern, wodurch der Angreifer gezwungen wird, jeden Hash einzeln zu erzwingen.

crypt speichert einfach das Salz und den Hasch zusammen mit dem zu verwendenden Algorithmus in einer einzigen Zeichenfolge.

Er würde immer noch einen separaten Tisch pro Ausweis brauchen. Solange dieses Schema nicht so verbreitet ist, dass jeder Angreifer ein paar Hunderttausend vorgenerierte Nachschlagetabellen herumliegen lässt, würde es keinen Gewinn geben. troelskn
Ich denke, das Problem mit einer eindeutigen Benutzer-ID für ein Salt ist, dass der Angreifer möglicherweise eine separate Nachschlagetabelle für jedes Salt hat, was nicht möglich wäre, wenn das Salt eine lange zufällige Zeichenfolge wäre. Paul Lynch
8

da Sie den Arbeitsfaktor von 4 auf 31 einstellen können. Jedes Inkrement erzeugt eine exponentielle benötigte Zeit. Ich habe es tatsächlich grafisch dargestellt. Bei einem Arbeitsfaktor von 14 dauert es bereits über eine Sekunde, damit Computer immer schneller werden Sie müssen nur einen Parameter ändern und natürlich Ihre Passwort-Hashes aktualisieren ...

Mein Hauptanliegen bei bcrypt ist, dass, wenn der Arbeitsfaktor hoch eingestellt ist, Ihr System möglicherweise überlastet wird, da mehrere Benutzer versuchen, sich anzumelden, sodass Sie dies tun müssen, abhängig von der Anzahl der gleichzeitigen Anmeldungen und den Ressourcen Ihres Systems. ..

Es werden immer noch Salze benötigt, deren Hauptzweck darin besteht, Off-Line-Angriffe abzuwehren. Wenn der Salt-Space zu groß ist, kann der Gegner die Look-Up-Tabelle nicht generieren. 64-Bit-Salt scheint ein bisschen niedrig zu sein. Bcrypt hat 128 Ein bisschen Salz in Verbindung mit dem Arbeitsfaktor macht es zu einer ziemlichen Herausforderung für Offline-Angriffe ... und ja, das Salz sollte für jedes Passwort zufällig sein. bcrypt generiert eines für Sie. Wenn Sie für jedes Passwort dasselbe Salz verwenden, haben Sie es erstellt Es ist für den Gegner einfacher, alle Passwörter mithilfe eines Online-Angriffs zu komprimieren.

Bcrypt ist für Online-Angriffe besonders gut geeignet, wenn Sie den Arbeitsfaktor richtig eingestellt haben. Selbst wenn ich den Hash erhalte, um zu sagen, ob der 'Gegner' den Hash erlangt, macht es der Arbeitsfaktor sehr schmerzhaft, ein ganzes Wörterbuch durchzuarbeiten. Es dauert mehrere Tage, und wenn das Passwort nicht im Wörterbuch enthalten ist, stecke ich wirklich in Schwierigkeiten, da ein Brute-Force-Angriff episch sein wird. Der Passwort-Bit-Speicherplatz für bcrypt ist recht groß, wenn auch endlich :)

Sha256 mag jetzt ein bisschen Zeit in Anspruch nehmen, aber irgendwann werden Computer immer schneller und es wird ziemlich einfach für Angriffe, die Unix-Leute dachten, die Krypta sei so langsam, dass es niemals ein Problem gewesen wäre, und heute habe ich eine ausgeführt Online-Angriff in Sekunden, Offline-Angriff in Tagen, ein Brute-Force-Angriff (der den gesamten Passwort-Bit-Raum durchläuft) in Wochen ...

Wenn Sie möchten, dass das Salt so groß und zufällig wie möglich ist und nur Zahlen verwendet werden, ist es für mich einfacher, alle möglichen IDs zu durchlaufen.
Es kann jetzt eine Sekunde dauern, bis mehrere sha256 verfügbar sind, aber später wird es nicht mehr effektiv sein. Die Rechenleistung von Computern wächst exponentiell und Sie möchten einen Algorithmus, der als solcher konfiguriert werden kann.
Sie tun das Richtige, indem Sie Fragen stellen und Ihre Hausaufgaben machen. Wenn mehr Leute dies tun, würden wir nicht so viele Verstöße haben
Vielen Dank. Und als Folge davon bietet das Hinzufügen einer "app-weiten" Zeichenfolge (wie in meinem obigen Beispiel) zum Kennwort vor dem Hashing Vorteile? Scheint, als würde ein zufälliges Salz ausreichen, richtig? user1446426
@ JanusTroelsen Ich bin mir nicht sicher, was du damit meinstpoint 2Das, was Sie beschreiben, kann nicht auf Punkt 2 angewendet werden, da es einen konstanten Faktor annimmt, vorausgesetzt, ich war ziemlich zweideutig. Um den "Faktor" zu erhöhen, müssten Sie ihn richtig berechnen, um den CPU-Verbesserungen zu entsprechen, selbst wenn Sie bcrypt verwenden muss immer noch dasselbe tun, aber dafür ist es bereits gut eingestellt. Letztendlich werden sich die CPUs soweit verbessern, dass wir den gesamten Bit-Raum durchgehen können. Bis dahin haben wir (hoffentlich) etwas anderes herausgefunden ... Samy Vilar
Je nach Entropie wird es schwieriger, Offlineangriffe (Wörterbuch- und Brute-Force-Angriffe) auszuführen, da diese Zeichenfolgen nicht gefunden werden. Für Onlineangriffe, bei denen der Gegner sowohl den Hash als auch das Salt hat, ist dies nicht erforderlich Lassen Sie sich zur Verifizierung im Klartext halten. Wenn Ihre Datenbank oder Ihre Hashes also kompromittiert sind, sind Salze nicht von großem Nutzen. Denken Sie daran, dass Salze von Offline-Angriffen und vom Arbeitsfaktor abgeschreckte Online-Angriffe abgeschreckt sind geringes Vorkommen ... bcrypt mit einem angemessenen Arbeitsfaktor sollte gut sein. Samy Vilar
zu Punkt 2: Kann ein wiederholt angewendeter Hash nicht exponentiell skaliert werden? Ich behaupte, dass es möglich ist, sie können so oft wie gewünscht angewendet werden. Zum Beispiel wende ich heute 10 ^ 3-mal sha-512 an. morgen wende ich es 10 ^ 4 an. Janus Troelsen
Diese Antwort ist ein hilfreicher Anfang, könnte aber verbessert werden, indem 1) "Online" - oder "Offline" -Angriffe definiert werden (wie hier gemeint - normalerweise bedeuten diese Begriffe, ob jemand mit dem Internet verbunden ist, aber ich denke, Sie meinen etwas anderes ); 2) Erklären, warum der "app-weite" String hilft (was meiner Meinung nach nur dann hilft, wenn der Angriff Zugriff auf die Datenbank bietet, nicht aber auf den Code); 3) Inwiefern ist der Optimierungsparameter von bcrypt einfacher (oder besser) zu verwenden als ein einzelner Parameter, der als Exponent zur Steuerung der Anzahl von SHA256-Anwendungen verwendet wird, wie Janus Troelsens Kommentar angibt. Paul Lynch

Verwandte Fragen