Wie hash lange Passwörter (>72 Zeichen) mit blowfish

Das problem hier ist im Grunde ein problem der Entropie. Beginnen wir also dort suchen:

Entropie Pro Zeichen

Die Anzahl der bits der Entropie pro byte:

• Hex-Zeichen
  • Bits: 4
  • Werte: 16
  • Entropie In 72 Chars: 288 bits
• Alpha-Numerische
  • Bits: 6
  • Werte: 62
  • Entropie In 72 Chars: 432 bits
• "Common" - Symbole
  • Bits: 6.5
  • Werte: 94
  • Entropie In 72 Chars: 468 bits
• Volle Bytes
  • Bits: 8
  • Werte: 255
  • Entropie In 72 Chars: 576 bits

So, wie wir handeln, hängt davon ab, welche Art von Zeichen, das wir erwarten.

Das Erste Problem

Das erste problem mit Ihrem code, ist, dass Ihr "Pfeffer" hash Schritt ist die Ausgabe von hex-Zeichen (da der vierte parameter hash_hmac() ist nicht gesetzt).

Daher, die von der Vermischung Ihre Pfeffer auf, Sie sind effektiv schneiden der maximalen Entropie zur Verfügung, um das Passwort von einem Faktor 2 (aus 576 288 möglich bits).

Das Zweite Problem

Jedoch sha256 nur 256 bits der Entropie in den ersten Platz. So sind Sie effektiv schneiden eine mögliche 576 bit auf 256 bit. Ihre hash-Schritt * sofort*, per definition verliert
mindestens 50% der möglich Entropie des Passworts.

Konnte Sie teilweise lösen diese durch den Wechsel zu SHA512, wo Sie würde nur eine Reduzierung der verfügbaren Entropie von etwa 12%. Aber das ist immer noch ein nicht unbedeutender Unterschied. Dass 12% reduziert die Anzahl der Permutationen mit einem Faktor von 1.8e19. Das ist eine große Nummer... Und das ist die Faktor es reduziert es durch...

Das Zugrunde Liegende Problem

Das zugrunde liegende Problem ist, dass es drei Arten von Kennwörtern über 72 Charaktere. Die Auswirkungen, die dieser style-system hat auf Sie wird sehr unterschiedlich sein:

Hinweis: von hier aus gehe ich davon aus wir sind im Vergleich zu einem Pfeffer-system SHA512 mit raw-Ausgabe (nicht hex).

• Hohe Entropie, zufällige Passwörter

  Diese sind Ihre Benutzer mit Passwort-Generatoren, die zu generieren, was Zeit zu einem großen Schlüssel für die Passwörter. Sie sind zufällig (generiert, die kein Mensch gewählt), und haben eine hohe Entropie pro Zeichen. Diese Typen sind mit high-bytes (Zeichen > 127) und einige steuerzeichen.

  Für diese Gruppe, Ihre Hash-Funktion wird deutlich reduzieren Sie Ihre verfügbaren Entropie in bcrypt.

  Lassen Sie mich sagen, dass wieder. Für Anwender, die mit hoher Entropie, lange Passwörter, Ihre Lösung deutlich reduziert die Stärke Ihres Passworts durch eine messbare Menge. (62 bits der Entropie verloren für eine 72-Zeichen-Passwort, und mehr, für längere Passwörter)

• Medium der Entropie, zufällige Passwörter

  Dieser Gruppe ist die Verwendung von Passwörtern mit gemeinsamen Symbolen, aber keine high-bytes oder-Zeichen. Dies sind Ihre typable Passwörter.

  Für diese Gruppe, Sie gehen zu leicht entsperren mehr Entropie (nicht erstellen, sondern damit mehr Entropie, um fit in den bcrypt-Passwort). Wenn ich sage etwas, meine ich leicht. Der break-even tritt auf, wenn Sie max aus den 512 bits, SHA512 hat. Also, der peak ist bei 78 Zeichen.

  Lassen Sie mich sagen, dass wieder. Für diese Klasse von Passwörtern, Sie können nur speichern Sie eine zusätzliche 6 Zeichen, bevor Sie laufen von Entropie.

• Niedrige Entropie nicht-zufällige Passwörter

  Dies ist die Gruppe, die mit alpha-numerischen Zeichen, die wohl nicht zufällig generiert werden. So etwas wie eine Bibel zitieren, oder so. Diese Sätze haben rund 2,3 bit Entropie pro Zeichen.

  Für diese Gruppe, können Sie deutlich entsperren mehr Entropie (nicht erstellen, sondern die es ermöglichen, mehr passen in die bcrypt Passwort-Eingabe), die von der Vermischung. Die Gewinnschwelle ist rund 223 Zeichen, bevor Sie laufen von Entropie.

  Lassen Sie uns sagen, dass wieder. Für diese Klasse von Passwörtern, pre-hashing jeden Fall erhöht die Sicherheit erheblich.

Zurück Zu Der Realen Welt

Diese Art der Entropie-Berechnungen nicht wirklich wichtig, viel in der realen Welt. Was zählt, ist zu raten, die Entropie. Das ist, was direkt Auswirkungen, was die Angreifer tun können. Das ist, was Sie wünschen, zu maximieren.

Zwar gibt es wenig Forschung, die den Weg in guessing entropy, gibt es einige Punkte, die ich möchte darauf hinweisen.

Die Chancen, nach dem Zufallsprinzip erraten 72 richtige Zeichen in einer Zeile sind extrem gering. Sie sind eher zu gewinnen, der Powerball Lotterie-21-Zeiten, als diese Kollision... Das ist, wie groß eine Zahl, die wir sprechen.

Aber wir können nicht stolpern auf es statistisch. Im Fall der Sätze, die chance, die ersten 72 Zeichen dasselbe ist, eine ganze Menge größer als für ein zufälliges Kennwort. Aber es ist immer noch trivial gering (Sie sind wahrscheinlicher zu gewinnen, die Lotterie Powerball 5 mal, basierend auf 2.3 bits pro Zeichen).

Praktisch

Praktisch, es spielt eigentlich keine Rolle. Die Chancen, jemanden zu raten, die ersten 72 Zeichen rechts, wo der letztere einen signifikanten Unterschied so gering, dass es nicht Wert sich Gedanken über. Warum?

Nun, sagen wir, du nimmst einen Satz. Wenn die person, die den ersten 72 Zeichen richtig, Sie sind entweder wirklich glücklichen (wahrscheinlich nicht), oder es ist ein weit verbreiteter Satz. Wenn es eine Allgemeine phrase, die einzige variable ist, wie lange es zu machen.

Nehmen wir ein Beispiel. Nehmen wir ein Zitat aus der Bibel (nur weil es eine gemeinsame Quelle der lange text, nicht aus einem anderen Grund):

Du sollst nicht Begehren deines nächsten Haus. Du sollst nicht Begehren deines nächsten Frau, oder seinen Knecht oder Magd, seinen Ochsen oder Esel oder irgendetwas, das gehört zu Ihren Nachbarn.

Dass 180 Zeichen. Der 73 Zeichen ist die g im zweiten neighbor's. Wenn Sie Ahnen, dass viel, du bist wahrscheinlich nicht zu stoppen, bei nei, aber weiter mit dem rest des verses (denn das ist, wie das Passwort ist wahrscheinlich verwendet werden). Daher, Ihrer "hash" nicht viel hinzuzufügen.

BTW: ich bin ABSOLUT NICHT dafür, mit einem Bibel-Zitat. In der Tat, genau das Gegenteil.

Abschluss

Du bist nicht wirklich zu helfen Menschen viel wer lange Passwörter, die von der Vermischung ersten. Einige Gruppen können Sie auf jeden Fall helfen. Einige können Sie auf jeden Fall verletzt.

Aber am Ende, nichts davon ist allzu bedeutend. Die zahlen, die wir beschäftigen, sind nur WEG zu hoch. Der Unterschied in der Entropie ist nicht zu viel.

Du bist besser dran verlassen bcrypt, wie es ist. Du bist eher zu vermasseln die hashing (buchstäblich, Sie haben es bereits getan, und Sie sind nicht die ersten, oder letzten, die diesen Fehler machen), als der Angriff, den Sie versuchen zu verhindern, dass passieren.

Den Schwerpunkt auf die Sicherung der rest der Seite. Und fügen Sie einen Passwort-Entropie-meter, um die Kennwort-Feld auf der Anmeldung angeben, Passwort Stärke (und zeigt an, wenn ein Kennwort überlangen, dass der Benutzer kann es ändern möchten)...

Das ist meine $0,02, mindestens (oder möglicherweise mehr als $0.02)...

So Weit Wie Mit Einem "Geheimnis" Pfeffer:

Gibt es praktisch keine Forschung in der Fütterung eine hash-Funktion in bcrypt. Daher ist unklar, am besten, wenn die Fütterung eine "gepfeffert" bcrypt-hash wird immer Ursache unbekannter Sicherheitslücken (wir wissen, tun hash1(hash2($value)) aussetzen erhebliche Schwachstellen rund um Kollision Widerstand und preimage-Angriffe).

Wenn man bedenkt, dass Sie bereits über die Speicherung eines geheimen Schlüssels (der "Pfeffer"), warum nicht verwenden es in einer Weise, die gut untersucht und verstanden? Warum nicht verschlüsseln des hash vor, um es zu speichern?

Grundsätzlich, nachdem Sie das Kennwort gehasht, füttern, das ganze hash-Ausgabe in eine starke Verschlüsselungs-Algorithmus. Dann speichern Sie das verschlüsselte Ergebnis.

Nun eine SQL-Injection-Angriff wird nicht Auslaufen, etwas nützliches, da Sie nicht über die Ziffer-Taste. Und wenn der Schlüssel zugespielt, die Angreifer sind nicht besser dran, als wenn Sie einen einfachen hash (was nachweisbar ist, etwas mit dem Pfeffer "pre-hash" nicht).

Hinweis: wenn Sie wählen, dies zu tun, verwenden Sie eine Bibliothek. Für PHP, ich stark empfehlen Zend Framework 2 Zend\Crypt Paket. Es ist eigentlich die einzige, die ich empfehlen würde, an diesem aktuellen Punkt in der Zeit. Es wurde stark überarbeitet, und es trifft alle Entscheidungen für Sie (das ist eine sehr gute Sache)...

Etwas wie:

use Zend\Crypt\BlockCipher;

public function createHash($password) {
    $hash = password_hash($password, PASSWORD_BCRYPT, ["cost"=>$this->cost]);

    $blockCipher = BlockCipher::factory('mcrypt', array('algo' => 'aes'));
    $blockCipher->setKey($this->key);
    return $blockCipher->encrypt($hash);
}

public function verifyHash($password, $hash) {
    $blockCipher = BlockCipher::factory('mcrypt', array('algo' => 'aes'));
    $blockCipher->setKey($this->key);
    $hash = $blockCipher->decrypt($hash);

    return password_verify($password, $hash);
}

Und es ist von Vorteil, weil man alle algorithmen in einer Weise, die gut verstanden werden und gut untersucht sind (relativ zumindest). Denken Sie daran:

Jedermann, von den meisten ahnungslosen amateur zu den besten Kryptologen, kann ein Algorithmus, der er selbst kann nicht brechen.

• Bruce Schneier

Bcrypt verwendet einen Algorithmus, basierend auf der teuren Blowfish-key-setup-Algorithmus.

Den empfohlenen 56-byte-Passwort-Grenzwert (einschließlich der null-Terminierung-byte) für bcrypt bezieht sich auf die 448-bit-Grenze der Blowfish-key. Alle bytes, die über diese Grenze nicht vollständig gemischt in den resultierenden Hashwert. Die 72 byte absolute limit auf bcrypt-Passwörter ist daher weniger relevant, wenn Sie den tatsächlichen Einfluss auf den resultierenden hash durch diese bytes.

Wenn Sie denken, dass Ihre Benutzer normalerweise wählen Sie Kennwörter über 55 bytes lang ist, denken Sie daran, Sie können immer erhöhen die Runden Kennwort ein stretching statt, zur Erhöhung der Sicherheit im Falle eines Passwort-Tabelle der Verletzung (obwohl diese eine Menge im Vergleich mit dem hinzufügen von zusätzlichen Zeichen). Wenn die Zugriffsrechte der Benutzer sind so kritisch, dass Nutzer in der Regel erfordern würde einen Massiv langen Passwort ein, dann das Passwort-Ablauf sollte auch kurz sein, z.B. 2 Wochen. Dies bedeutet, dass ein Passwort ist viel weniger wahrscheinlich ist, gültig bleiben, während ein hacker investiert Ihre Ressourcen in das besiegen der Arbeit Faktor bei der Prüfung jeder Versuch das Passwort zu sehen, ob es einen passenden hash.

Natürlich, im Falle der Passwort-Tabelle nicht verletzt werden, sollten wir nur Hackern erlaubt, höchstens zehn versuchen zu erraten eines Benutzers 55 byte-Passwort, bevor Sie sperren das Konto des Benutzers aus 😉

Wenn Sie sich entschließen, pre-hash ein Passwort, das mehr als 55 bytes, dann sollten Sie verwenden, SHA-384, da es die größte Ausgabe, ohne über die Grenze.