Der Hauptgrund für die Verwendung einer bestimmten Passwort-Hashing-Funktion besteht darin, Angreifern das Leben zu erschweren oder genauer zu verhindern, dass sie ihr eigenes Leben leichter machen (im Vergleich zu dem des Verteidigers). Insbesondere möchte der Angreifer möglicherweise mehr Hashes pro Sekunde (dh versuchen Sie mehr Kennwörter pro Sekunde) mit einem bestimmten Budget mithilfe einer GPU berechnen.

Insbesondere SHA-256 profitiert stark von der Implementierung auf einer GPU. Wenn Sie also SHA-256-crypt verwenden, sind Angreifer im Vorteil als wenn Sie bcrypt verwenden, das in einer GPU nur schwer effizient zu implementieren ist.

Siehe diese Antwort für eine Diskussion von bcrypt vs PBKDF2. Obwohl SHA-256-crypt nicht PBKDF2 ist, ist es in seinem Leistungsverhalten auf der GPU ähnlich genug, sodass die gleichen Schlussfolgerungen gelten.

Der Fall für SHA-512 ist etwas weniger klar, da vorhandene GPUs viel besser sind Bei Verwendung von 32-Bit-Ganzzahlen als 64-Bit verwendet SHA-512 hauptsächlich 64-Bit-Operationen. Es wird weiterhin erwartet, dass moderne GPUs mit SHA-512-crypt mehr Hashes pro Sekunde als CPU (für ein bestimmtes Budget) zulassen, was wiederum auf bcrypt als die bessere Wahl hinweist.

Die SHA-2-Familie von Hashes wurde so konzipiert, dass sie schnell ist. BCrypt wurde entwickelt, um langsam zu sein. Beide gelten als robust. Mit genügend Runden oder Arbeitsfaktor kann eine länger dauern als die andere, aber ich würde mich zu der neigen, die so konzipiert wurde, dass sie langsam ist. (Wenn die Serverlast ein Problem darstellt, ist der Arbeitsfaktor anpassbar.)

Außerdem würde ich mich zu BCrypt neigen, da es sich normalerweise um eine kompilierte Implementierung (C oder C ++) handelt.

Das Multi -round SHA kann leicht in einer höheren Sprache implementiert werden, zumindest für die Iteration, wenn nicht auch für den Hash selbst. Hochsprachen sind für grundlegende mathematische Operationen weniger effizient und reduzieren die Anzahl der Runden, die Ihre Produktionshardware pro Millisekunde ausführen kann.

Beide Algorithmen können entweder in Hoch- oder Niedrigsprachen oder in einem Hybrid implementiert werden. In BCrypt schreiben die verfügbaren Optionen vor, dass Sie eher auf eine effiziente Implementierung stoßen . (bringt Sie mit dem Angreifer auf ein ausgeglicheneres Spielfeld)

In Bezug auf Ihr spezielles Beispiel aus der Datei / etc / shadow befinden Sie sich wahrscheinlich nur auf niedriger Ebene ( effiziente) Algorithmen so oder so. (SHA oder BCrypt) In diesem Beispiel würde ich vorschlagen, dass Sie die Dokumentation des Betriebssystems konsultieren, um die Runden (Arbeitsfaktor) basierend auf der Geschwindigkeit der Hardware zu optimieren - vs- wie stark der Hash sein soll

Verschlüsselung (mit einem ausreichend großen Arbeitsfaktor) bietet den zusätzlichen Vorteil, dass zusätzliche RAM- / Speicheranforderungen (nicht nur CPU) erforderlich sind, wodurch die GPU-Beständigkeit erhöht wird als SHA, BCrypt oder PBKDF2.

Bearbeiten: Vielen Dank an Thomas für den Hinweis, dass BCrypt GPU-resistenter als SHA-2 ist und dass SHA-2 und PBKDF2 praktisch sind gleichwertig in dieser Hinsicht.

Hinweis: Ich betrachte diese Frage nach dieser Bearbeitung und berücksichtige sie:

Hinweis: Ich meine speziell die Mehrrunden-Passwort-Hashes, die in den verknüpften Dokumenten beschrieben und in Krypto-Hashes mit den Codes $ 5 $ und $ 6 $ gekennzeichnet sind, nicht eine einzige Runde der einfachen SHA256- oder SHA512-Hash-Funktionen.

Wenn Sie sich den langen 22-Schritte-Algorithmus in diesem Link ansehen, den Sie bereitgestellt haben, möchte ich lieber eine Frage umdrehen: Warum sollten Sie diesen Algorithmus lieber anstelle von PBKDF2 mit HMAC-SHA2? Zumindest wie dargestellt:

• Die Definition von PBKDF2 sieht viel einfacher aus. Dies liegt daran, dass es modularer ist - es verschiebt den größten Teil seiner Arbeit auf ein externes gelieferte Pseudozufallsfunktion. Dies wird normalerweise mit HMAC instanziiert, was wiederum den größten Teil seiner Arbeit auf eine externe Hash-Funktion wie SHA-1 oder SHA-2 verschiebt.
• Dies bedeutet, dass die Sicherheit von PBKDF2 sollte einfacher zu analysieren sein.

Im Gegensatz dazu listet der Algorithmus in dem von Ihnen bereitgestellten Dokument eine Menge Schritte auf, deren Motivation schwerer zu verstehen ist. Zum Beispiel:

  11. Für jedes Bit der binären Darstellung der Länge der Kennwortzeichenfolge bis einschließlich der höchsten 1-stelligen Zahl, beginnend mit der niedrigsten Bitposition (numerischer Wert 1): a) Fügen Sie für eine 1-stellige Zusammenfassung Digest B zu Digest A b hinzu ) Fügen Sie für eine 0-stellige Kennwortzeichenfolge hinzu. Hinweis: Dieser Schritt unterscheidet sich erheblich vom MD5-Algorithmus. Es fügt mehr Zufälligkeit hinzu.  

Es fügt mehr Zufälligkeit hinzu? Wie macht es das? Warum gibt es diesen Schritt überhaupt - fügt SHA-2 nicht genügend Zufälligkeit hinzu? Wenn SHA-2 nicht zufällig genug ist, warum sollte es überhaupt verwendet werden? Und führt dieser Schritt nicht geheime abhängige Verzweigung in den Algorithmus ein und wirft die Frage nach möglichen Timing-Angriffen gegen ihn auf?

Ich sage keineswegs, dass die von Ihnen verknüpften Algorithmen unsicher sind. Es ist nur so:

• Der von ihnen eingeführte Arbeitsfaktor hängt von der gleichen Funktion ab, die PBDKF2 - HMAC-SHA2 ausführen würde (eine große Anzahl von SHA2-Iterationen).
• Sie ähneln weitgehend dem, was Sie hätten Wenn Sie eine PBKDF2-HMAC-SHA2-Implementierung abgewickelt haben, aber mit zusätzlicher Komplexität, deren Zweck ich nicht verstehe;
• Also zumindest wie in diesen Dokumenten dargestellt, fällt es mir schwerer Vertrauen in ihr Design zu gewinnen als ich für PBKDF2.

BEARBEITEN: Nachdem ich das alles geschrieben hatte, ging ich ein bisschen in diesen Algorithmus, um ihn besser zu verstehen. Zunächst erfahren wir aus den Links "Beschreibung" und "Spezifikation" der Frage, dass der Algorithmus durch relativ geringfügige Änderungen von einem älteren MD5-basierten abgeleitet wurde / p>

Dieser ältere MD5-basierte Algorithmus scheint der zu sein, den Poul-Henning Kamp 1994 für FreeBSD-2.0 geschrieben hat, den er nicht mehr für sicher hält. Im ersten Link (wo er die Geschichte der Funktion erzählt) erwähnt er, dass glibc auch seine Funktion übernommen hat. Er verweist auch auf das Papier von Provos und Mazières aus dem Jahr 1999 über bcrypt und erwähnt, dass es etwas Missbilligung ausdrückt, und komischerweise haben sie denselben Schritt hervorgehoben, der meine Aufmerksamkeit oben erregt hat:

MD5 crypt hascht das Kennwort und das Salt in verschiedenen Kombinationen, um die Auswertungsgeschwindigkeit zu verlangsamen. Einige Schritte im Algorithmus lassen Zweifel daran aufkommen, dass das Schema unter kryptografischen Gesichtspunkten entworfen wurde. Beispielsweise bestimmt die binäre Darstellung der Kennwortlänge zu einem bestimmten Zeitpunkt, welche Daten gehasht werden, für jedes Nullbit das erste Byte des Kennworts und für jedes gesetzte Bit das erste Byte einer vorherigen Hash-Berechnung.

Aber ich denke, dies erklärt die Motivation der neueren Funktionen, nach denen Sie fragen: Sie sind eine sehr minimale Modifikation einer älteren Funktion, die älter ist als die meisten modernen Passwort-Hash-Funktionen, deren Design in Frage gestellt wurde, aber wahrscheinlich nicht grundlegend gebrochen, nur sinnlos komplex.

Die SHA-2-Familie selbst ist nicht unbedingt schlecht. Von Natur aus gibt es keine wirklichen Sicherheitslücken, die bcrypt oder scrypt vorzuziehen machen. Das Problem, das viele Sicherheitsexperten mit SHA haben, ist jedoch, dass es zu schnell ist und nicht viel Speicher benötigt. Im Vergleich dazu ist eine Hashing-Funktion wie das Verschlüsseln sozusagen viel langsamer und teurer.

Das Verschlüsseln erfordert eine angemessene Menge an Speicher, um berechnet zu werden. Zusätzlich zu all diesem Speicher und vor allem aufgrund des Bedarfs an Speicher benötigt Scrypt im Vergleich zu SHA viel Rechenzeit. Diese Antwort von der BitCoin Stack Exchange-Site fasst die Vorteile von scrypt recht gut zusammen: Welche Funktionen von scrypt () machen Tenebrix GPU-resistent? Im Wesentlichen ist scrypt so konzipiert, dass es langsam und speicherintensiv ist. GPUs mögen das nicht. GPUs verfügen im Allgemeinen nicht über die Speicherkapazität, um den gesamten für die Verschlüsselungsberechnung erforderlichen Speicher zu speichern, ohne auf Ausführungsblockierungsmethoden zurückgreifen zu müssen ( wobei die GPU alle Threads blockiert, da sie nur Werte aus dem gemeinsam genutzten Speicher abrufen kann Zeit ), und daher können GPUs in Bezug auf die Verarbeitungszeit keinen großen Vorteil gegenüber CPUs bieten. Bcrypt ist ähnlich.

Bcrypt hat sich beim Passwort-Hashing bewährt. Es gibt es seit 17 Jahren und es erledigt immer noch die Arbeit. Eines Tages wird die GPU-Technologie jedoch so weit fortgeschritten sein, dass sie bcrypt schneller und effizienter berechnen kann als eine CPU. Die Technologie entwickelt sich ständig weiter und wird sich irgendwann weiterentwickeln. Wenn dieser Tag kommt, wird bcrypt keine gute Wahl mehr für das Hashing von Passwörtern sein, und Kryptographen und Sicherheitsexperten müssen bcrypt durch einen ähnlichen Algorithmus ersetzen, der langsamer und speicherintensiver als der vorhandene bcrypt ist. Vielleicht wird das verschlüsselt, aber wer soll das sagen? Warum ist SHA verpönt?

SHA wird im Allgemeinen nicht aufgrund von Sicherheitslücken, sondern aufgrund der Geschwindigkeit und der Fähigkeit, auf einer GPU implementiert zu werden, nicht empfohlen. Jemand mit unbegrenzter Maschinen- / Rechenleistung könnte jede Art von Hashing-Algorithmus knacken, sei es SHA, bcrypt oder scrypt, aber das ist theoretisch. In der Praxis verfügt ein Angreifer nicht über eine unbegrenzte Anzahl von Computern, auf denen er versuchen kann, Hashes zu knacken. Je mehr Sie diesen Angreifer verlangsamen können, desto schwieriger wird es für ihn, ein Kennwort zu knacken. Es gibt ein Budgetlimit für alles und das Knacken von Passwörtern ist keine Ausnahme. Der Angreifer kann Passwörter nur so schnell knacken, wie es sein Budget zulässt. ( Die beste Technologie, die sie innerhalb ihres Budgets erwerben können, die Kosten für den Betrieb dieser Technologie (z. B. Stromkosten) usw. ) Natürlich können Sie mehrere SHA-Runden implementieren, um einen Angreifer erheblich zu verlangsamen , aber warum nicht einfach an diesem Punkt bcrypt verwenden? Mit dem Fortschritt der GPU-Technologie in naher Zukunft müssen Sie Ihren SHA-Berechnungen unter anderem immer mehr Runden / Iterationen hinzufügen, um sie so langsam zu machen, dass sie langsamer als bcrypt ist. Mit dem Fortschritt der GPU-Technologie bleibt bcrypt jedoch unphasiert, bis zu dem Punkt, an dem die GPU-Technologie eine effiziente Berechnung von bcrypt ermöglicht. Daher ist bcrypt nach Möglichkeit die bevorzugte Wahl, nicht weil SHA unsicher ist, sondern weil SHA zu recheneffizient ist.

Nun, eines der Merkmale von bcrypt ist, dass es sich um einen sehr langsamen Algorithmus handelt. Diese Langsamkeit bietet eine zusätzliche Sicherheit für Brute-Force-Angriffe. Aus dem gleichen Grund ist es möglicherweise nicht die beste Lösung, zum Beispiel für stark genutzte Webserver, da hier ein hoch aufgeladener Computer diese schwere Berechnung bei jedem Login durchführen muss.

Aber solange Ihr System kann akzeptieren, dass zusätzliche Zeit Brute-Force-Angreifer tatsächlich stört.