Salt (Kryptologie)
Salt (englisch für Salz) bezeichnet in der Kryptographie eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext vor dessen weiterer Verarbeitung (z. B. Eingabe in eine Hashfunktion) angehängt wird, um die Entropie der Eingabe zu erhöhen. Es wird häufig für die Speicherung und Übermittlung von Passwörtern benutzt, um die Informationssicherheit zu erhöhen.
Motivation
Passwörter werden nicht direkt gespeichert, sondern beim Anlegen eines Kontos gehasht, und der Hash wird in der Datenbank mit den Benutzerdaten gespeichert. Bei Anmeldung eines Benutzers wird sein dabei eingegebenes Passwort gehasht und mit dem gespeicherten Hash verglichen, um den Benutzer zu authentifizieren.
Kryptographische Hashfunktionen wie z. B. BLAKE oder SHA-2 erzeugen für unterschiedliche Klartexte (z. B. unterschiedliche Passwörter) fast sicher jeweils unterschiedliche Hash-Werte. Aus der Kollisionsresistenz der Hashfunktion folgt, dass die Wahrscheinlichkeit, dass für zwei unterschiedliche Passwörter der gleiche Hashwert erzeugt wird, so klein ist, dass sie in der Praxis vernachlässigt werden kann. Jedoch ist der Hash zu einem gegebenen Passwort stets derselbe. Daher kann man an gleichen Hashwerten ziemlich sicher erkennen, welche Benutzer dasselbe Passwort gewählt haben.[1]
Bei Wörterbuch-Angriffen, bei denen man viele mögliche Passwörter der Reihe nach hasht und das Ergebnis mit den aus der Datenbank gestohlenen Passwort-Hashes vergleicht, muss man jedes Passwort nur ein einziges Mal hashen und das Resultat mit den Hashes aller Benutzer vergleichen, um festzustellen, ob irgendeiner der Benutzer dieses Passwort gewählt hat. Die Kenntnis von Passwort-Hashes vieler Benutzer vervielfacht somit die Erfolgsaussichten. Durch Verwendung leistungsfähiger paralleler Hardware (oft Grafikkarten) und optimierter Algorithmen kann man typischerweise viele Millionen Passwörter pro Sekunde hashen.
Für viele Hashalgorithmen liegen außerdem bereits sogenannte Rainbow Tables vor, die eine Menge von möglichen Passwörtern (z. B. alle Wörter eines Wörterbuchs) mit Hashwerten in Beziehung setzen. Wenn ein gegebener Hashwert von einem Passwort aus dieser Menge stammt, lässt sich dieses Passwort damit wesentlich schneller finden als durch systematisches Durchprobieren aller Passwörter.
Salt
Wo die Anmeldung über das Internet oder andere Netzwerke erfolgt, werden die Zugangsdaten häufig mit Salts versehen. Ein Passwort wird nicht mehr direkt gehasht, sondern es wird zusammen mit dem Salt in die Hashfunktion eingegeben. Das Salt ist entweder für alle Benutzer das gleiche, oder es wird für jeden Benutzer bei dessen Kontoerstellung zufällig erzeugt.[2]
Bereits die Verwendung eines konstanten (für alle Benutzer gleichen) Salts verhindert es, die für bekannte Hashfunktionen vorbereiteten Rainbow-Tables zu verwenden, denn durch den Salt ist die Abbildung der Passwörter auf die Hashwerte eine andere. Man könnte zwar im Prinzip Rainbow-Tabellen für Passwort-Salt-Kombinationen erstellen, aber bei einer genügend großen Zahl von möglichen Salts ist das völlig unpraktikabel. Sie müssten alle unterstützten Passwörter in jeder Kombination mit den möglichen Salts enthalten – bei Bit langem Salt wäre die Anzahl der in der Tabelle zu erfassenden Klartexte -mal so groß wie zuvor.[3]
Ein systematisches Durchprobieren der Passwörter ist damit aber noch genauso möglich, da ein Angreifer, der auf den Datenbankinhalt zugreifen kann, in der Regel auch den Salt herausfindet. Dies wird erschwert, wenn für jeden Benutzer ein eigener Salt erzeugt wird, den man zusammen mit dem Hashwert und den übrigen Benutzerdaten speichert. Nun ist ein aus Probepasswort und Salt berechneter Hashwert nur noch für den Benutzer mit diesem Salt gültig. Jedes Probepasswort muss für jeden Benutzer erneut gehasht werden. Außerdem ergeben zwei zufällig gleich gewählte Passwörter unterschiedlicher Benutzer nicht mehr den gleichen Hashwert, sofern der zufällige Salt nicht gleich ist.
Pepper
Um Wörterbuch- und Brute-Force-Angriffe weiter zu erschweren, kann das Passwort mit einer vom Server gewählten und geheimgehaltenen Zeichenfolge kombiniert werden, bevor der Hashwert berechnet wird. Diese Zeichenfolge wird Pepper (Pfeffer)[4] genannt und ist normalerweise für alle Passwörter auf einem Server gleich. Wenn der Pepper zusätzlich noch jeweils für jedes Passwort geändert wird, kann die Sicherheit weiter erhöht werden. Der Pepper wird nicht in derselben Datenbank gespeichert wie der Hashwert, sondern an einem anderen und möglichst sicheren Ort hinterlegt. Erlangt ein Angreifer nur Zugriff auf die Datenbank (z. B. per SQL-Injection), so erfährt er zwar immer noch die Hash-Werte, diese stammen aber nun von Kombinationen von Passwort und einem unbekannten Pepper. Ein Wörterbuchangriff ist sinnlos, weil kein Wörterbuch zufällig eine der Passwort-Pepper-Kombinationen enthalten wird. Auch ein Brute-Force-Angriff wird drastisch erschwert, weil man nicht nur die Passwörter durchprobieren muss, sondern die Kombinationen aus Passwort und Pepper.
Häufig wird empfohlen, einen HMAC zu verwenden, um Passwort (dort als geheimer Schlüssel ) und Pepper (dort als Nachricht ) zu kombinieren,[5] da dann die Kollisionsresistenz der Hashfunktion nicht mehr ausschlaggebend für die Sicherheit der Gesamtkonstruktion ist.[6]
Praxis
Es gibt speziell zum Hashen von Passwörtern entwickelte Hashfunktionen, z. B. bcrypt, scrypt und Argon2. Diese erlauben auch eine Abstimmung des Hash-Aufwandes, um dem Angreifer beim Probieren der möglichen Passwörter ebenfalls den höheren Aufwand aufzubürden. Das ist das gleiche Prinzip wie bei der Schlüsselstreckung. Erhöht man gegenüber einer normalen kryptographischen Hashfunktion wie etwa SHA-2 den zum Hashen nötigen Aufwand um den Faktor n, dann muss auch der Angreifer für jedes Passwort die n-fache Zeit aufwenden, d. h., er kann in einer gegebenen Zeit um den Faktor n weniger Passwörter probieren und hat entsprechend geringere Erfolgsaussichten. Das Hashen mit beispielsweise SHA-2 benötigt auf einem modernen Rechner weniger als 10−6 Sekunden, und n kann somit, je nach der Frequentierung des Servers und der verfügbaren Rechenleistung, oft größer als 1000 gewählt werden.
Stand der Technik ist für diesen Zweck Argon2, das auch dafür ausgelegt wurde, den Einsatz von speziell entwickelter Hardware (ASICs) zu erschweren. Der Benutzer kann nicht nur den Zeitaufwand, sondern auch den verwendeten Speicherplatz und die Parallelität (Zahl der eingesetzten Prozessorkerne) bestimmen.
Unterschied zu Nonce und Padding
Eine Nonce und das Padding sind einem Salt sehr ähnlich, da es ebenfalls Zeichenfolgen sind, die im Programm bzw. Algorithmus nicht ausgewertet oder anders verwendet werden als sie einfach einer anderen Zeichenkette anzuhängen. Der Unterschied liegt in dem Zweck und der genauen Anwendung dieser Zeichenketten.
Während ein Salt bei Passwörtern zum Erhöhen der Entropie benutzt wird, werden Nonce und Padding in Verschlüsselungsalgorithmen benutzt. Die Nonce dient dabei dazu, die „Einmaligkeit“ eines Klartextes sicherzustellen, sodass sich trotz determinierter Vorgehensweise des Algorithmus der erzeugte Ciphertext unterscheidet, wenn der gleiche Klartext mehrmals verschlüsselt wird. Somit sollte die Nonce auch möglichst zufällig sein.
Padding muss dagegen das Kriterium der Zufälligkeit meist nicht zwingend erfüllen und dient meist dazu, die Ermittlung der Länge eines Klar- und Ciphertextes zu erschweren, oder die Länge auf die Blocklänge zu erhöhen.
Probleme
Bildet ein Verfahren aufgrund eines Programmierfehlers oder einer fehlerhaften Implementierung z. B. nur 1000 unterschiedliche Salts, kann das Erstellen einer Rainbow Table weiterhin lohnend sein. Derartige Fälle werden als „schwache“ Salts bezeichnet. Ein solches Verfahren sind die von Windows-Systemen (XP, Vista) angelegten, zwischengespeicherten Anmeldeinformationen (DCC, Domain Cached Credentials, von Cracking-Programmen auch als MS-Cache-Hashes bezeichnet). Der Benutzername wird dabei als Salt verwendet. Rainbow Tables können daher weiterhin für weit verbreitete Benutzernamen erzeugt werden, z. B. administrator.
Gegen Brute-Force-Angriffe oder Wörterbuchangriffe, bei denen für verschiedene Eingaben geprüft wird, ob sie zum Hashwert passen, hat ein Salt keine sicherheitssteigernde Wirkung. Hierfür sind zusätzlich rechnerisch aufwändige Berechnungen zwischenzuschalten (key stretching), deren Zweck es ist, ein Durchprobieren bis zur praktischen Nutzlosigkeit zu verlangsamen. Ein Beispiel dafür ist der PBKDF2-Algorithmus, der häufig beim Speichern von Passwörtern zum Einsatz kommt.
Siehe auch
Einzelnachweise
- ↑ Passwort – Sicherer mit Hash und Salt. In: Datenschutzbeauftragter INFO 11. März 2013, abgerufen am 5. November 2013
- ↑ Sicheres Speichern von Passwörtern – Versalzen wir die Suppe. www.martinstoeckli.ch Abgerufen am 30. Oktober 2013
- ↑ Cracker-Bremse – Bremsfaktor. In: c't 13/2011, Seite 148 Abgerufen am 30. Oktober 2013
- ↑ Sicheres Speichern von Passwörtern – Geben wir noch etwas Pfeffer dazu. www.martinstoeckli.ch Abgerufen am 30. Oktober 2013
- ↑ Tom Leek: What is the purpose of a Pepper? In: Information Security. Stack Exchange Inc, 4. September 2013, abgerufen am 30. Mai 2017 (englisch).
- ↑ Prof. Dr. Eike Kilt: Hashfunktionen und Kollisionen. (pdf) In: CRYPTO RUB. Ruhr Universität Bochum, abgerufen am 29. Juni 2018.
