Salt (Kryptologie)

Grundidee und Zweck

Ein Salt ist in der Kryptographie eine zufällig gewählte Zeichenfolge, die an einen Klartext angehängt wird, bevor dieser weiterverarbeitet wird, zum Beispiel als Eingabe in eine Hashfunktion. Besonders häufig wird ein Salt bei Passwörtern verwendet. Ziel ist es, die Entropie der Eingabe zu erhöhen und dadurch die Informationssicherheit bei Speicherung und Übermittlung von Passwörtern zu verbessern.

Passwörter werden normalerweise nicht im Klartext gespeichert. Beim Anlegen eines Kontos wird das Passwort gehasht, und nur der Hashwert wird zusammen mit den Benutzerdaten in der Datenbank gespeichert. Bei der Anmeldung wird das eingegebene Passwort erneut gehasht und mit dem gespeicherten Hash verglichen. Kryptographische Hashfunktionen wie BLAKE oder SHA-2 sind kollisionsresistent: Unterschiedliche Eingaben erzeugen fast sicher unterschiedliche Hashwerte. Deshalb kann man sich in der Regel nur mit dem richtigen Passwort anmelden.

Angriffe auf Passwort-Hashes

Wenn zwei Hashwerte übereinstimmen, kann man mit hoher Sicherheit annehmen, dass die zugehörigen Passwörter gleich sind. Das kann ein Angreifer ausnutzen, wenn er die Hashwerte aus einer Benutzerdatenbank kennt und weiß, welche Hashfunktion verwendet wurde. Er kann mögliche Passwörter ausprobieren, sie hashen und mit den gespeicherten Hashwerten vergleichen. Ein solcher Angriff mit häufigen oder wahrscheinlichen Passwörtern heißt Wörterbuch-Angriff.

Ohne Salt muss ein Angreifer jedes Probepasswort nur ein einziges Mal hashen, um zu prüfen, ob irgendein Benutzer dieses Passwort gewählt hat. Je mehr Passwort-Hashes aus einer Datenbank bekannt sind, desto größer werden die Erfolgsaussichten. Mit leistungsfähiger paralleler Hardware, oft GPGPU, und optimierten Algorithmen lassen sich typischerweise viele Millionen Probepasswörter pro Sekunde hashen.

Zusätzlich gibt es für viele Hash-Algorithmen vorberechnete Rainbow Tables. Das sind Tabellen, die mögliche Passwörter, zum Beispiel alle Wörter eines Wörterbuchs, mit Hashwerten in Beziehung setzen. Wenn ein Hashwert von einem Passwort aus dieser Menge stammt, kann das Passwort wesentlich schneller gefunden werden als durch systematisches Durchprobieren aller Passwörter.

Verwendung von Salt

In der Praxis werden Passwörter häufig mit Salts versehen. Das Passwort wird dann nicht allein gehasht, sondern zusammen mit dem Salt in die Hashfunktion eingegeben. Das Salt wird in der Regel für jeden Benutzer bei der Kontoerstellung zufällig erzeugt und zusammen mit dem Hashwert und den übrigen Benutzerdaten in der Datenbank gespeichert.

Schon ein konstanter Salt, der für alle Benutzer gleich ist, würde vorbereitete Rainbow Tables für bekannte Hashfunktionen unbrauchbar machen, weil sich durch den Salt die Abbildung von Passwörtern auf Hashwerte verändert. Noch wirksamer ist aber ein eigener Salt pro Benutzer. Zwar könnte man theoretisch Rainbow Tables für Passwort-Salt-Kombinationen erstellen, doch bei genügend vielen möglichen Salts ist das praktisch nicht machbar. Bei einem Salt mit n Bit müssten 2^n-mal so viele Klartexte in der Tabelle erfasst werden wie ohne Salt.

Ein Salt verhindert das systematische Durchprobieren von Passwörtern nicht vollständig, denn ein Angreifer mit Zugriff auf die Datenbank erfährt in der Regel auch den Salt. Der entscheidende Vorteil ist aber: Da jeder Benutzer einen eigenen Salt hat, ist ein aus Probepasswort und Salt berechneter Hashwert nur noch für diesen einen Benutzer gültig. Jedes Probepasswort muss für jeden Benutzer erneut gehasht werden.

Pepper und Passwort-Hashfunktionen

Ein Pepper ist eine zusätzliche, geheim gehaltene Zeichenfolge, die beim Einrichten des Servers gewählt und zusammen mit Passwort und Salt zur Berechnung des Hashwerts verwendet werden kann. Anders als der Salt wird der Pepper nicht in derselben Datenbank wie der Hashwert gespeichert, sondern an einem anderen, möglichst sicheren Ort. Erlangt ein Angreifer nur Zugriff auf die Datenbank, kennt er zwar die Hashwerte, aber nicht den Pepper. Dadurch werden Wörterbuch- und Brute-Force-Angriffe deutlich erschwert, weil Kombinationen aus Passwort und Pepper geprüft werden müssten. Normalerweise ist der Pepper für alle Passwörter auf einem Server gleich; unterschiedliche Pepper pro Passwort können die Sicherheit weiter erhöhen.

Häufig wird empfohlen, für die Kombination von Passwort und Pepper einen HMAC zu verwenden. Dabei entspricht das Passwort dem geheimen Schlüssel K und der Pepper der Nachricht M. Dadurch ist die Kollisionsresistenz der Hashfunktion nicht mehr ausschlaggebend für die Sicherheit der Gesamtkonstruktion.

Neben Salt und Pepper gibt es speziell für Passwörter entwickelte Hashfunktionen wie bcrypt, scrypt und Argon2. Sie erlauben, den Aufwand einer Hash-Berechnung einzustellen. Wird der Aufwand gegenüber einer normalen kryptographischen Hashfunktion wie SHA-2 um den Faktor n erhöht, muss auch ein Angreifer für jedes Probepasswort die n-fache Zeit aufwenden. Er kann dann in derselben Zeit um den Faktor n weniger Passwörter testen. SHA-2 benötigt auf einem modernen Rechner weniger als 10^{−6} Sekunden; n kann daher je nach Serverauslastung und Rechenleistung oft größer als 1000 gewählt werden. Als Stand der Technik gelten für diesen Zweck unter anderem Argon2 und Yescrypt. Sie wurden auch dafür ausgelegt, speziell entwickelte Hardware wie ASICs zu erschweren. Einstellbar sind nicht nur Zeitaufwand, sondern auch Speicherplatz und Parallelität, also die Zahl der eingesetzten Prozessorkerne.

Abgrenzung und Grenzen

Salt ähnelt einer Nonce und Padding, weil auch diese Zeichenfolgen an andere Zeichenketten angehängt werden und im Programm oder Algorithmus nicht inhaltlich ausgewertet werden. Der Zweck ist jedoch unterschiedlich. Ein Salt wird bei Passwörtern verwendet, um die Entropie zu erhöhen. Eine Nonce wird in Verschlüsselungsalgorithmen genutzt, um die Einmaligkeit eines Klartextes sicherzustellen. Dadurch soll bei mehrfacher Verschlüsselung desselben Klartextes trotz determinierter Vorgehensweise ein unterschiedlicher Ciphertext entstehen. Deshalb sollte eine Nonce möglichst zufällig sein. Padding dient meist dazu, die Ermittlung der Länge von Klartext und Ciphertext zu erschweren oder die Länge auf die Blocklänge zu erhöhen; Zufälligkeit ist dabei meist nicht zwingend erforderlich.

Salts haben auch Grenzen. Wenn ein Verfahren wegen eines Programmierfehlers oder einer fehlerhaften Implementierung nur wenige verschiedene Salts erzeugt, zum Beispiel nur 1000, kann das Erstellen einer Rainbow Table weiterhin lohnend sein. Solche Fälle heißen schwache Salts. Als Beispiel nennt der Artikel die von Windows-Systemen XP und Vista angelegten, zwischengespeicherten Anmeldeinformationen DCC, Domain Cached Credentials, von Cracking-Programmen auch MS-Cache-Hashes genannt. Dabei wird der Benutzername als Salt verwendet, sodass Rainbow Tables weiterhin für verbreitete Benutzernamen wie administrator erzeugt werden können.

Gegen Brute-Force-Angriffe oder Wörterbuchangriffe, bei denen viele Eingaben darauf geprüft werden, ob sie zu einem Hashwert passen, hat ein Salt allein keine sicherheitssteigernde Wirkung. Dafür braucht man zusätzlich rechenaufwändige Verfahren, die das Durchprobieren stark verlangsamen. Dieses Prinzip heißt Key Stretching. Ein häufig eingesetztes Beispiel beim Speichern von Passwörtern ist der PBKDF2-Algorithmus.