Passwort-Hashing für Entwickler – Warum bcrypt, Argon2 und scrypt sicherer sind als MD5

Ich erinnere mich noch an die Tage, als ich zum ersten Mal ein Anmeldesystem erstellt habe. Das Benutzerpasswort habe ich damals direkt als Klartext in der MySQL-Datenbank gespeichert. Es fühlt sich praktisch an: Einloggen, einfach password_input == password_database vergleichen, fertig. Erst nachdem ich einen Artikel über Datenlecks gelesen hatte, wurde mir klar, dass diese Praxis so war, als würde man Hausschlüssel unter der Fußmatte vor der Tür aufbewahren. Es sieht einfach aus, aber sobald jemand die Matte anhebt, öffnen sich alle Türen.

Von da an begann ich, etwas über Passwort-Hashing zu lernen. Es stellt sich heraus, dass es beim Speichern von Passwörtern nicht darum geht, den Text zu verbergen, sondern ihn in eine Darstellung umzuwandeln, die nicht rückgängig gemacht werden kann – nicht einmal durch den Systembesitzer. Dieser Artikel ist eine Aufzeichnung meiner Reise zum Verständnis von bcrypt, Argon2, scrypt und warum alte Algorithmen wie MD5 nicht mehr für den Einsatz geeignet sind.

Hashing ist keine Verschlüsselung, und das ist wichtig

Viele Anfänger denken, dass Hashing und Verschlüsselung dasselbe sind. Auch wenn die beiden unterschiedlich sind, wie ein Briefkasten und ein Safe. Bei der Verschlüsselung handelt es sich um einen Safe, der mit einem Schlüssel wieder geöffnet werden kann. Beim Hashing handelt es sich um ein Postfach, bei dem Buchstaben nur eingegeben, aber nicht abgerufen werden können. Das Ergebnis ist, dass es nach dem Eintreten keinen Ausweg mehr gibt.

Wenn wir ein Passwort hashen, möchten wir nicht in der Lage sein, es auf den Originaltext zurückzusetzen. Alles, was wir brauchen, ist die Fähigkeit zu überprüfen: Erzeugt das Passwort, das der Benutzer beim Anmelden eingibt, denselben Hash wie der gespeicherte? Wenn ja, wird der Zugriff akzeptiert. Wenn nicht, lehnen Sie ab.

Dieses Konzept wird Einwegfunktion genannt. Funktionen, die in eine Richtung leicht auszuführen, aber sehr schwer umzukehren sind. Stellen Sie sich das so vor, als würden Sie einen Smoothie zubereiten: Es ist einfach, Obst zu pürieren, aber es ist fast unmöglich, es wieder in ganze Äpfel, Bananen und Mangos zu zerlegen.

Warum reichen MD5 und SHA1 nicht mehr aus?

In der Vergangenheit war MD5 König. Alle frühen PHP-Tutorials verwendeten md5($password). Doch mit der Zeit zeigte MD5 einen fatalen Fehler: Es war zu schnell. Geschwindigkeit ist normalerweise ein Vorteil beim Rechnen, aber im Zusammenhang mit Passwort-Hashing geht Geschwindigkeit tatsächlich nach hinten los.

Je schneller ein Algorithmus einen Hash generiert, desto schneller kann ein Angreifer Milliarden von Passwortkombinationen in einer Sekunde ausprobieren. Diese Technik wird Brute-Force oder Wörterbuchangriff genannt. Mit einer modernen GPU kann ein einzelner Computer Billionen von MD5-Hashes pro Sekunde ausprobieren. Passwörter wie „P@ssw0rd123“ können in wenigen Minuten geknackt werden.

Darüber hinaus ist MD5 auch anfällig für Kollision: Zwei verschiedene Eingaben können denselben Hash erzeugen. Auch wenn die Kollision das Passwort nicht direkt preisgibt, zeigt sie, dass die MD5-Struktur nicht mehr solide ist. Genau wie das Fundament eines zerbrochenen Hauses – es mag zwar noch stehen, aber nicht bewohnbar.

SHA1 hat ein ähnliches Problem. Beide sind auf Geschwindigkeit und nicht auf Passwortsicherheit ausgelegt. Sie eignen sich hervorragend für Dateiprüfsummen, sind jedoch fehl am Platz, wenn sie zum Speichern von Anmeldeinformationen verwendet werden.

Salz: Lassen Sie jeden Hash einzigartig sein

Bevor wir uns mit modernen Algorithmen befassen, gibt es ein wichtiges Konzept: Salz. Stellen Sie sich vor, Sie machen Instantnudeln. Wenn alle die gleichen Gewürze verwenden, sind die Ergebnisse gleich. Aber wenn jede Person eine kleine andere geheime Zutat hinzufügt – einen Löffel Sojasauce, eine Prise Chili, einen halben Löffel Sesamöl – dann schmecken dieselben Nudeln anders. Das ist Salz

Beim Hashing ist ein Salt eine zufällige Zeichenfolge, die einem Passwort hinzugefügt wird, bevor es gehasht wird. Das Salt wird zusammen mit dem Hash in der Datenbank gespeichert. Selbst wenn also zwei Benutzer das Passwort „123456“ haben, sind ihre Hashes unterschiedlich, da ihre jeweiligen Salts unterschiedlich sind. Dies zerstört die Effizienz der Regenbogentabelle, einer vorberechneten Hash-Tabelle für gängige Passwörter.

Ohne Salt kann ein Angreifer den durchgesickerten Hash mit einer Rainbow-Tabelle abgleichen und sofort das Passwort finden. Mit Salt müssen sie jeden Hash einzeln angreifen, was den Prozess drastisch verlangsamt. Aber Salz allein reicht nicht aus, wenn der Grundalgorithmus immer noch schnell ist wie MD5.

bcrypt: Ein alter Standard, dem immer noch vertraut wird

bcrypt ist ein Passwort-Hashing-Algorithmus, der speziell für die Verlangsamung entwickelt wurde. Es kombiniert Salze intern, sodass Entwickler Salze nicht manuell verwalten müssen. Das Interessanteste: bcrypt verfügt über einen Kostenfaktor-Parameter, der bestimmt, wie viele Iterationen durchgeführt werden. Mit steigender Hardwaregeschwindigkeit kann der Kostenfaktor steigen.

In PHP wird bcrypt automatisch über die Funktionen password_hash() und password_verify() verwendet. Dies ist eine der besten APIs, die mir je begegnet sind: einfach, sicher, unfehlbar und benutzerfreundlich.

 12]);
// $hash berisi salt + cost + hash dalam satu string

// Saat login
if (password_verify($password, $hash)) {
    // Login berhasil
}

// Upgrade cost factor jika perlu
if (password_needs_rehash($hash, PASSWORD_BCRYPT, ['cost' => 13])) {
    $hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 13]);
}
?>

Übliche Kostenwerte liegen derzeit zwischen 10 und 13. Je höher, desto langsamer der Hashing-Prozess. Normalerweise wählen wir einen Kostenfaktor, der dafür sorgt, dass der Hashing-Prozess etwa 250–500 Millisekunden dauert. Das ist langsam genug, um Brute-Force-Angriffe zu verhindern, aber dennoch praktisch für einen einzelnen angemeldeten Benutzer.

Argon2: Champion des Passwort-Hashing-Wettbewerbs

Argon2 war der Gewinner des Password Hashing Competition 2015. Es wurde so konzipiert, dass es Angriffen mit spezieller Hardware wie GPUs und ASICs besser standhält. Argon2 hat drei Varianten: Argon2d, Argon2i und Argon2id. Für Passwörter wird Argon2id am meisten empfohlen, da es den besten Schutz vor verschiedenen Arten von Angriffen bietet.

Das Besondere an Argon2 ist die Verwendung von speicherhartem. Dabei wird nicht nur die CPU belastet, sondern auch der Arbeitsspeicher. Dies macht Angriffe mit GPUs deutlich teurer, da GPUs in der Regel über begrenzten Speicher pro Thread verfügen. Eine Analogie: Wenn bcrypt Angreifer laufen lässt, lässt Argon2 sie laufen, während sie große Steine ​​auf dem Rücken tragen.

In PHP 7.2+ ist Argon2 als Standardoption für password_hash() verfügbar. Die Konfiguration ist etwas komplexer als bei bcrypt, da es drei Parameter gibt: Speicherkosten, Zeitkosten und Threads.

 65536,  // 64 MB
    'time_cost'   => 4,      // iterasi
    'threads'     => 3       // parallelism
]);

// Verifikasi tetap sama
if (password_verify($password, $hash)) {
    // Login berhasil
}
?>

Die oben genannten Parameter können je nach Serverkapazität angepasst werden. Es ist wichtig, keinen zu niedrigen Wert zu wählen, da dies den Schutz vor Hardware-Angriffen verringert. Andererseits kann ein zu hoher Wert bei vielen gleichzeitigen Anmeldungen den Server überlasten.

scrypt: Eine zuverlässige speicherintensive Alternative

scrypt ist ein speicherintensiver Algorithmus, der von Colin Percival entwickelt wurde. Das Hauptziel ist dasselbe wie bei Argon2: Brute-Force mit dedizierter Hardware ineffizient zu machen. scrypt war in der Welt der Kryptowährungen, einschließlich Litecoin, weit verbreitet, bevor es von Argon2 überholt wurde.

Auch wenn Scrypt den Wettbewerb nicht gewonnen hat, gilt es dennoch als sicher und wird in einigen Systemen verwendet. Der Unterschied zu bcrypt: bcrypt ist hinsichtlich der CPU-Kosten begrenzter, während scrypt auch Speicherkosten verursacht. Wenn bcrypt so ist, als würde man eine Tür mit vielen Schlüsseln abschließen, verschließt scrypt die Tür mit vielen Schlüsseln und verengt den Raum dahinter, so dass man ihn nur schwer bewegen kann.

In PHP ist Scrypt nicht nativ über password_hash() verfügbar. Wenn Sie es nutzen möchten, benötigen Sie in der Regel zusätzliche Erweiterungen oder Bibliotheken von Drittanbietern. Für die meisten modernen Webanwendungen ist bcrypt oder Argon2 mehr als ausreichend.

Pfeffer: Eine zusätzliche Ebene voller Geheimnisse

Neben Salz gibt es einen Begriff, der weniger häufig diskutiert wird: Pfeffer. Wenn Salz eine einzigartige Zutat ist, die zusammen mit dem Hash gespeichert wird, dann ist Pfeffer ein globales Geheimnis, das getrennt von der Datenbank gespeichert wird. Normalerweise wird Pepper in der Serverkonfigurationsdatei oder Umgebungsvariablen gespeichert, nicht in der Datenbank.

Die Funktion von Pepper besteht darin, eine zusätzliche Schutzebene bereitzustellen, wenn die Datenbank durchgesickert ist. Ein Angreifer, der nur einen Datenbank-Dump erhält, kann das Passwort nicht überprüfen, ohne den Pepper zu kennen. Es ist, als hätte man zu Hause einen Safe mit zwei Schlüsseln: Ein Schlüssel befindet sich im Safe selbst, der andere ist immer in der Tasche.

Pfeffer sollte jedoch mit Vorsicht verwendet werden. Wenn Pepper verloren geht oder geändert wird, sind alle Passwörter nicht mehr überprüfbar. Es ist kein Ersatz für Salz, sondern eine Ergänzung. Der übliche Ablauf ist: Passwort + Salz kombinieren, hashen, dann die Ergebnisse mit Pfeffer kombinieren, erneut hashen.

Best Practices, die ich anwende

Nachdem ich verschiedene Algorithmen verstanden hatte, kam ich zu einigen grundlegenden Vorgehensweisen, die ich immer anzuwenden versuche:

• Speichern Sie Passwörter niemals im Klartext oder mit umkehrbarer Verschlüsselung.
• Verwenden Sie password_hash() und password_verify() in PHP; Erstellen Sie keinen eigenen Hashing-Algorithmus.
• Wählen Sie Argon2id, falls verfügbar, Fallback auf bcrypt mit hohem Kostenfaktor.
• Verwenden Sie für jedes Passwort ein eindeutiges und automatisches Salt.
• Implementieren Sie starke Passwortrichtlinien sowohl auf der Client- als auch auf der Serverseite, aber denken Sie daran, dass Richtlinien allein kein gutes Hashing ersetzen.
• Erwägen Sie eine Ratenbegrenzung und Kontosperrung, um Brute-Force-Angriffe zu verhindern.
• Bereiten Sie einen Reaktionsplan für Vorfälle vor, falls die Datenbank geleakt wird, einschließlich der Aufforderung an Benutzer, ihre Passwörter zu ändern.

Das Wichtigste von allem: Haben Sie niemals das Gefühl, dass Sicherheit eine einmalige Aufgabe ist. Sicherheit ist ein Prozess. Ein Algorithmus, der heute als sicher gilt, ist morgen möglicherweise nicht mehr sicher. Deshalb sind Funktionen wie password_needs_rehash() so nützlich: Sie ermöglichen es uns, die Sicherheit schrittweise zu erhöhen, ohne den Benutzer zu stören.

Schlussfolgerung

Passwort-Hashing ist eine der Grundlagen der Anwendungssicherheit, die oft unterschätzt wird. Tatsächlich kann ein Fehler hier fatale Folgen haben, wenn Daten durchsickern. MD5 und SHA1 sind zwar noch in vielen alten Tutorials zu finden, für die Speicherung von Passwörtern sind sie jedoch nicht die richtige Wahl. Verwenden Sie bcrypt, Argon2id oder scrypt – Algorithmen, die auf Verlangsamung und Widerstandsfähigkeit gegen moderne Angriffe ausgelegt sind.

Für mich ist das Verständnis von Passwort-Hashing so, als würde man lernen, sein Haus richtig abzuschließen. Ein guter Schlüssel muss nicht kompliziert sein, aber er muss stimmen. Und vor allem müssen wir wissen, warum der Schlüssel gewählt wurde.

Wenn Sie weitere Erfahrungen oder Meinungen zum Passwort-Hashing haben, hinterlassen Sie diese bitte in der Kommentarspalte. Es macht mir Spaß, aus verschiedenen Blickwinkeln zu lernen. Wenn dieser Artikel nützlich ist, zögern Sie nicht, ihn zu teilen.