Best Practices: Salzen & amp; Passwörter pfeffern?

Stieß ich auf eine Diskussion, in der ich lernte, dass das, was ich getan, war nicht in der Tat Passwörter Salzen, sondern würzen Sie, und ich habe da begonnen die beiden mit einer Funktion wie:

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

Ignorieren des gewählten hash-Algorithmus (ich will, dass das eine Diskussion von Salzen & Paprika und nicht konkrete algorithmen sondern ich bin mit einem secure), ist dies eine sichere option, oder sollte ich etwas anderes zu tun? Für diejenigen, die nicht vertraut mit den Begriffen:

  • Einen Salz ist eine zufällig generierte Wert in der Regel gespeichert mit dem string in der Datenbank sollen es unmöglich machen, zu verwenden hash-tables die Passwörter zu Cracken. Wie jedes Kennwort hat seinen eigenen salt, müssen Sie alle brute-gezwungen, einzeln, um zu knacken; aber als das Salz in der Datenbank gespeichert ist mit dem Passwort-hash, Datenbank Kompromiss bedeutet verlieren.
  • Einen Pfeffer ist ein site-wide statischen Wert getrennt von der Datenbank gespeichert (in der Regel hart codiert in der Anwendung source-code), die bestimmt ist, geheim. Es ist so, dass sich ein Kompromiss der Datenbank würde nicht dazu führen, die gesamte Anwendung Passwort-Tabelle brute-forceable.

Ist es etwas, was ich bin fehlt, und ist das Salzen & pfeffere meine Passwörter die beste option zum Schutz meiner user ' s security? Gibt es eine potenzielle Sicherheitslücke, es zu tun auf diese Weise?

Hinweis: nehmen Sie für die Zwecke der Diskussion, dass die Anwendung & Datenbank gespeichert werden, auf separaten Maschinen, nicht teilen, Passwörter, etc. also ein Verstoß gegen die Datenbank-server bedeutet nicht automatisch eine Verletzung des application Servers.

InformationsquelleAutor der Frage Glitch Desire | 2013-06-03

  1. 270

    Ok. Zu sehen, wie ich brauche, um zu schreiben über diese über und überich werde tun, eine Letzte kanonische Antwort auf Pfeffer allein.

    Die Scheinbare Oberseite Der Paprika

    Scheint es ganz offensichtlich, dass die Paprika sollten hash-Funktionen sicherer. Ich meine, wenn der Angreifer bekommt nur Ihre Datenbank, dann Ihre Benutzer-Passwörter sollten sicher sein, richtig? Scheint logisch, oder?

    Das ist, warum so viele Menschen glauben, dass Paprika sind eine gute Idee. Es "macht Sinn".

    Die Realität Paprika

    In die Sicherheit und Kryptographie reichen, "Sinn machen" ist nicht genug. Es muss etwas sein, beweisbar und Sinn machen, damit es als sicher angesehen werden. Es ist außerdem zu werden, implementierbar in einer nachhaltigen Art und Weise. Das sicherste system kann nicht beibehalten werden, gilt als unsicher (weil wenn ein Teil dieser Sicherheit bricht das ganze system auseinander fällt).

    Und Paprika passen weder beweisbar oder wartbarer Modelle...

    Theoretische Probleme, Mit Paprika

    Nun, wir haben die Bühne, schauen wir uns an, was ist falsch mit Paprika.

    • Fütterung einen hash in einen anderen gefährlich werden kann.

      In Ihrem Beispiel, Sie tun hash_function($salt . hash_function($pepper . $password)).

      Wir aus der Vergangenheit wissen, dass "nur füttern" ein hash-Ergebnis in eine andere hash-Funktion kann, um die Allgemeine Sicherheit. Der Grund dafür ist, dass beide hash-Funktionen kann ein Ziel des Angriffs.

      Deshalb algorithmen wie PBKDF2 spezielle Operationen zu kombinieren (hmac in diesem Fall).

      Der Punkt ist, dass, während es ist nicht eine große Sache, es ist auch nicht eine triviale Sache, nur werfen Sie herum. Krypto-Systeme sind entworfen, um zu vermeiden, "sollte funktionieren" - Fälle, und konzentrieren Sie sich stattdessen auf "ausgelegt" - Fällen.

      Während dieses scheinen kann, rein theoretisch, es ist in der Tat nicht. Zum Beispiel, Bcrypt nicht akzeptieren können beliebige Passwörter. So übergeben bcrypt(hash(pw), salt) kann in der Tat Ergebnis in einer sehr viel schwächeren hash als bcrypt(pw, salt) wenn hash() gibt einen Binär-string.

    • Arbeiten Gegen Design -

      Den Weg bcrypt (und anderen Passwort-hashing-algorithmen) entworfen wurden, ist die Zusammenarbeit mit einem Salz. Das Konzept der Pfeffer wurde nie eingeführt. Dies mag wie eine Trivialität, aber es ist nicht. Der Grund dafür ist, dass ein Salz ist kein Geheimnis. Es ist nur ein Wert, der bekannt ist für einen Angreifer. Pfeffer, auf der anderen Seite, durch definition, ist ein Kryptografisches Geheimnis.

      Dem aktuellen Kennwort-hashing-Algorithmus (bcrypt, pbkdf2, etc) alle sind so konzipiert, nur in einem geheimen Wert (das Passwort). Hinzufügen in ein Geheimnis, in das der Algorithmus noch nicht erforscht.

      Das bedeutet nicht, dass es nicht sicher ist. Es bedeutet, dass wir nicht wissen, ob es sicher ist. Und die generelle Empfehlung, die mit Sicherheit und Verschlüsselung und ist, dass, wenn wir nicht wissen, ist es nicht.

      So, bis die algorithmen entwickelt und geprüft, die von Kryptologen für den Einsatz mit Geheimnis-Werte (Paprika), aktuelle algorithmen verwendet werden sollte nicht mit Ihnen.

    • Komplexität Ist Der Feind Der Sicherheit

      Ob Sie es glauben oder nicht, Komplexität Ist Der Feind Der Sicherheit. Machen Sie einen Algorithmus, der sieht kompliziert aus, kann sicher sein, oder kann es nicht. Aber die Chancen sind erheblich, dass es nicht sicher ist.

    Erhebliche Probleme Mit Paprika

    • Es ist Nicht Verwaltbar

      Ihre Umsetzung Paprika schließt die Fähigkeit, drehen Sie die Pfeffer-Taste. Da der Pfeffer wird an der Eingabe für das one-way-Funktion, können Sie sich nie ändern Pfeffer für die Lebensdauer des Wertes. Dies bedeutet, dass Sie brauchen würde um zu kommen mit einigen wonky-hacks, um es zur Unterstützung der key rotation.

      Dies ist extrem wichtig wie es ist immer dann erforderlich, wenn Sie speichern Sie kryptographische Geheimnisse. Nicht mit einem Mechanismus zum drehen (Tasten regelmäßig, und nach einer Verletzung) ist eine riesige Sicherheitslücke.

      Und Ihre aktuelle Pfeffer Ansatz müssten alle Benutzer haben entweder Ihr Passwort völlig entkräftet durch eine Drehung, oder warten bis zu Ihrem nächsten login zu drehen (die nie)...

      Welche im Grunde macht dein Ansatz, eine sofortige no-go.

    • Es Erfordert, Dass Sie Roll Your Own Crypto

      Da keine aktuellen Algorithmus unterstützt das Konzept der Pfeffer, der es erfordert, dass Sie entweder verfassen algorithmen oder neue erfinden, zu unterstützen, Pfeffer. Und wenn Sie können nicht sofort sehen, warum das ist eine wirklich üble Sache:

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

      NIE roll your own crypto...

    Der Bessere Weg

    So, aus all der Probleme, die oben detailliert beschrieben, es gibt zwei Wege im Umgang mit der situation.

    • Nur Die Algorithmen Verwenden, Wie Sie Vorhanden Sind

      Wenn Sie bcrypt oder scrypt korrekt (mit hohen Kosten), alle, aber die schwächsten Wörterbuch Passwörter sollten statistisch sicher. Der aktuelle Rekord für das hashing bcrypt bei Kosten 5 wird 71k hashes pro Sekunde. Zu diesem Satz noch eine 6-Zeichen Kennwort würde Jahre dauern, zu knacken. Und in Anbetracht meines empfohlene minimale Kosten 10, das reduziert die hashes pro Sekunde um einen Faktor von 32. So wären wir sprechen nur über 2200 hashes pro Sekunde. Zu diesem Satz, auch einige Wörterbuch Phrasen oder modificaitons kann sicher sein.

      Darüber hinaus sollten wir prüfen, für die schwachen Klassen von Passwörtern an der Tür und nicht was Ihnen im. Als Passwort-cracking-wird noch erweitert, so sollte das Passwort Qualitätsanforderungen. Es ist immer noch ein statistisches Spiel, aber mit der richtigen storage-Technik, und starke Passwörter, jeder sollte praktisch sehr sicher...

    • Verschlüsseln Die Ausgabe Hash Vor Der Lagerung

      Gibt es im security-realm ein Algorithmus entworfen, um alles, was wir weiter oben gesagt habe. Es ist ein block-Chiffre. Es ist gut, weil es reversibel, so können wir drehen, Schlüssel (yay! Wartbarkeit!). Es ist gut, weil es verwendet wird, wie entworfen. Es ist gut, denn es gibt dem Benutzer keine Informationen.

      Schauen wir uns diese Zeile wieder. Angenommen, ein Angreifer kennt Ihr Algorithmus (erforderlich für Sicherheit, ansonsten ist es security through obscurity). Mit einem traditionellen Pfeffer-Ansatz kann der Angreifer erstellen eine sentinel-Kennwort ein, und da er weiß, das Salz und den Ausgang, er kann brute-force-der Pfeffer. Ok, das ist eine lange gedreht, aber es ist möglich. Mit einer Ziffer, der Angreifer bekommt nichts. Und da das Salz ist randomisiert, eine sentinel-Passwort gar nicht mit ihm/Ihr helfen. Also das beste, was Sie mit Links sind ist ein Angriff auf die verschlüsselte form. Was bedeutet, dass Sie zuerst angreifen, Ihre verschlüsselten hash wiederherstellen des Verschlüsselungsschlüssels, und dann greifen die hashes. Aber es gibt eine viel der Forschung in den Angriff von Chiffren, so wollen wir uns auf das verlassen,.

    TL/DR

    Nicht verwenden peppers. Es gibt eine Reihe von Problemen mit Ihnen, und es gibt zwei bessere Wege: nicht mit jedem server-side-secret (ja, es ist ok) und der Verschlüsselung der Ausgabe-Hashwert mithilfe eines block-Chiffre vor der Einlagerung.

    InformationsquelleAutor der Antwort ircmaxell

  2. 16

    Faust sollten wir reden über die genaue Vorteil von einem Pfeffer:

    • Der Pfeffer schützen können schwache Passwörter aus einem Wörterbuch-Angriff, in dem speziellen Fall, wo der Angreifer lese-Zugriff auf die Datenbank (mit den hashes), aber keinen Zugriff auf den Quellcode, mit dem Pfeffer.

    Ein typisches Szenario wäre die SQL-injection, weggeworfen sicherungen, verworfen Servern... Diese Situationen sind nicht so ungewöhnlich wie es klingt, und oft nicht unter Ihrer Kontrolle sind (server-hosting). Wenn Sie...

    • Einem einzigartigen salt pro Passwort
    • Eine langsame hashing-Algorithmus wie BCrypt

    ...starke Passwörter gut geschützt sind. Es ist fast unmöglich für brute-force-ein starkes Passwort, unter diesen Bedingungen, auch wenn der salt bekannt ist. Das problem sind die schwachen Passwörter, die von einem brute-force-dictionary-oder Ableitungen davon. Ein Wörterbuch-Angriff offenbaren wird diese sehr schnell, weil Sie nur zum testen der häufigsten Passwörter.

    Die zweite Frage ist wie die Pfeffer ?

    Eine oft empfohlene Methode anzuwenden, Pfeffer, kombinieren Sie das Passwort und den Pfeffer vor der übergabe an die hash-Funktion:

    $pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

    Gibt es eine andere, noch bessere Weise, obwohl:

    $passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

    Dies ermöglicht nicht nur einen server hinzufügen Seite geheim, es ermöglicht auch einen Austausch der $serverSideKey, falls dies erforderlich sein sollte. Diese Methode bezieht mit ein bisschen mehr Arbeit, aber wenn der code einmal vorhanden ist (in der Bibliothek) gibt es keinen Grund, es nicht zu verwenden.

    InformationsquelleAutor der Antwort martinstoeckli

  3. 2

    Dem Punkt, Salz und Pfeffer zur Erhöhung der Kosten für eine vorberechnete Passwort-lookup, genannt rainbow-Tabelle.

    Im Allgemeinen versuchen, eine Kollision zu finden für einen einzelnen hash ist schwer (vorausgesetzt, die hash sicher ist). Allerdings, mit kurzen hashes, ist es möglich, computer zu generieren, die alle möglichen hashes in ein lookup auf eine Festplatte. Dies nennt man eine Rainbow-Table. Wenn Sie das erstellen einer rainbow-Tabelle können Sie dann hinausgehen in die Welt und finden schnell plausable Passwörter für jede (ungesalzene unpeppered) hash.

    Dem Punkt, der Pfeffer ist, um die rainbow-table benötigt, um hack Ihr Passwort Liste einzigartig. So verschwenden mehr Zeit auf die Angreifer zu konstruieren, die rainbow-table.

    Dem Punkt, der das Salz jedoch ist die rainbow-Tabelle für jeden Benutzer eindeutig sein, um dem Benutzer, eine weitere Erhöhung der Komplexität des Angriffs.

    Wirklich der Punkt der computer-Sicherheit ist fast nie zu machen (mathematisch) unmöglich, nur mathematisch und physisch unpraktisch (zum Beispiel in sichere Systeme, die es dauern würde, alle die Entropie im Universum (und mehr) zu berechnen, eine single-user-Passwort).

    InformationsquelleAutor der Antwort Aron

  4. 1

    Nicht sehen können, das speichern einer hartcodierten Wert in Ihrem source-code, als hätten Sie irgendeine Sicherheits-Relevanz. Es ist security through obscurity.

    Wenn ein hacker übernimmt die Datenbank, wird er in der Lage sein zu beginnen brute-zwingen Sie Ihre Benutzer-Passwörter. Es wird nicht lange dauern, dass die hacker zu identifizieren, Ihre Pfeffer, falls er es schafft zu knacken ein paar Passwörter.

    InformationsquelleAutor der Antwort Sven

Schreibe einen Kommentar