it-swarm-eu.dev

Pre-Hash-Passwort vor dem Anwenden von bcrypt, um die Passwortlänge nicht einzuschränken

Es wird empfohlen, die Kennwortlänge nicht unnötig einzuschränken, damit entsprechend lange Passphrasen (möglicherweise 35-45 Zeichen für 6/7 Wörterwörter) verwendet werden können. (Siehe z. B. Sollte ich eine maximale Kennwortlänge haben? wobei maximal 1 KB empfohlen wird, um vor DoS zu schützen, ohne die Fähigkeit der Benutzer einzuschränken, lange Kennwörter festzulegen.)

bcrypt wird auch häufig empfohlen (siehe z. B. Empfehlen Sicherheitsexperten bcrypt zur Kennwortspeicherung? , http://chargen.matasano.com/chargen/2007/9/7/enough- mit-den-Regenbogen-Tabellen-was-du-wissen-musst-über-s.html )

Es wird auch empfohlen, ein Salt zu verwenden (zufällig und mit dem Passwort-Hash gespeichert). Ich glaube, 32-Bit (4 Zeichen) werden oft empfohlen. (Ich verstehe das Grundprinzip der Salzgröße als "ausreichend, dass die Anzahl der Kombinationen viel größer ist als die Anzahl der Benutzerdatensätze UND ausreicht, um Rainbow-Tabellen unmöglich zu machen" - 16 Bit reichen für den zweiten Teil aus, sind es aber möglicherweise nicht genug für den ersten.)

AIUI bcrypt hasht jedoch nur 55 Bytes - mit 4 Zeichen für das Salz, das 51 für das Passwort übrig lässt.

Ich vermute, wir sollten nicht einfach verschlüsseln (links (Passwort, 51)) und die letzten Zeichen ignorieren.

Sollten wir Benutzer nur auf 50 Zeichen in ihrem Passwort beschränken (genug für fast alle, aber nicht definitiv genug)?

Sollten wir stattdessen so etwas wie bcrypt (sha256 (salt + password)) verwenden und bis zu 1K Zeichen zulassen? Oder verringert das Hinzufügen des Schritts sha256 (oder sha512?) Die Gesamtsicherheit irgendwie?

Haben Scrypt oder PBKDF2 ähnliche Längenbeschränkungen?

(Die letzte Frage ist wirklich nur von Interesse - mir ist klar, dass die Platzhärte/FPGA-Beständigkeit und die relative Neuheit von Scrypt sowie die GPGPU-Beständigkeit von bcrypt im Vergleich zu PBKDF2 weitaus wichtigere Überlegungen bei der Entscheidung sind, welcher Hash verwendet werden soll verwenden.)

65
Misha

Die Verwendung einer sicheren Hash-Funktion zur Vorverarbeitung des Kennworts ist sicher. Es kann gezeigt werden, dass, wenn bcrypt (SHA-256 (Passwort)) fehlerhaft ist, entweder das Passwort erraten wurde oder ein Sicherheitsmerkmal von SHA-256 als falsch erwiesen wurde. Auf dieser Ebene besteht keine Notwendigkeit, mit dem Salz herumzuspielen. Hash das Passwort, dann benutze bcrypt für das Ergebnis (mit dem Salz, als bcrypt Mandate). SHA-256 wird als sichere Hash-Funktion angesehen.

Der Punkt eines Salt soll eindeutig sein - so eindeutig wie möglich, damit keine zwei Hash-Passwörter denselben Salt-Wert verwenden. 32 Bits sind dafür etwas niedrig; Sie sollten ein längeres Salz verwenden. Wenn Sie n Salzstücke haben, treten Kollisionen (zwei gehashte Passwörter mit demselben Salz) auf, sobald Sie mehr als ungefähr 2) habenn/2 Hash-Passwörter - das sind ungefähr 65000 mit n = 32, einem nicht zu hohen Wert. Verwenden Sie besser 64 Bit oder mehr Salz (verwenden Sie 128 Bit und Sie können aufhören, sich darüber Sorgen zu machen).

39
Thomas Pornin

Bcrypt verwendet ein 128-Bit-Salt UND ein Passwort mit maximal 55 Zeichen. Sie müssen keine weiteren Salzwerte hinzufügen. bcrypt kümmert sich darum.

Die Entwickler von bcrypt waren der Meinung, dass die Beschränkung des Kennworts auf 55 Zeichen kein Problem darstellt, da der Hash eine 128-Bit-Ausgabe hat. Wenn Ihr Kennwort mehr als 55 Zeichen enthält, haben die Designer angenommen, dass Sie bereits mehr als 128 Bit Entropie bereitstellen, sodass dies kein Problem darstellt. Im Gegenteil, die NIST-Richtlinien würden dies als nur 77 Entropiebits zählen. Die NIST-Richtlinien basieren auf der Tatsache, dass Passphrasen weniger Entropie pro Zeichen aufweisen als zufällige Passwörter und auf der Annahme, dass Benutzer Passphrasen für längere Passwörter verwenden. Um sicherzustellen, dass Sie eine vollständige Entropie von 128 Bit erhalten, können Sie längere Kennwörter zulassen und diese mit SHA-256 oder SHA-384 hashen, um sie auf eine akzeptable Länge zu komprimieren. Sie können die Dinge auch einfach vereinfachen, indem Sie scrypt oder PBKDF2 verwenden, für die es keine Längenbeschränkungen gibt. Scrypt ist so konzipiert, dass es nicht nur rechenintensiv, sondern auch "speicherintensiv" ist. Das wäre meine Wahl der Algorithmen.

14