Salt (Kryptologie): Unterschied zwischen den Versionen

Aus Foxwiki
Zeile 17: Zeile 17:


; Es gibt zwei Techniken, um diese Situation zu verbessern
; Es gibt zwei Techniken, um diese Situation zu verbessern
* Verwendung von Salt (und evtl. auch Pepper)  
* Verwendung von Salt (evtl. auch Pepper)  
* Passwort-Hashfunktionen, die im Vergleich zu den auf Effizienz optimierten Funktionen wie etwa SHA-2 wesentlich mehr Aufwand je Hash-Berechnung erfordern, um Angriffe zu verlangsamen.
* Passwort-Hashfunktionen
*: die im Vergleich zu den auf Effizienz optimierten Funktionen wie etwa SHA-2 wesentlich mehr Aufwand je Hash-Berechnung erfordern, um Angriffe zu verlangsamen.


== Salt ==
== Salt ==

Version vom 14. April 2024, 17:06 Uhr

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.

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 sind kollisionsresistent, d. h. sie erzeugen aus unterschiedlichen Eingaben fast sicher unterschiedliche Hashwerte.
  • Die Wahrscheinlichkeit, dass verschiedene Passwörter den gleichen Hashwert ergeben, kann vernachlässigt werden, und somit kann man sich nur mit dem richtigen Passwort anmelden.

Das heißt aber auch, dass man aus der Übereinstimmung zweier Hashes mit hoher Sicherheit schließen kann, dass die jeweiligen Passwörter gleich sind, und ein Angreifer kann versuchen, die Passwörter durch Probieren zu finden.

  • Wer die Hashes aus einer Benutzerdatenbank kennt und auch weiß, welche Hashfunktion verwendet wurde, kann probeweise mögliche Passwörter hashen und mit den Hashes der Datenbank vergleichen, etwa in Form eines Wörterbuch-Angriffs.
  • Er muss dabei jedes Probepasswort nur ein einziges Mal hashen, um festzustellen, ob einer 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 GPGPU) und optimierter Algorithmen kann man typischerweise viele Millionen Probepasswörter pro Sekunde hashen.

Für viele Hash-Algorithmen 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.
Es gibt zwei Techniken, um diese Situation zu verbessern
  • Verwendung von Salt (evtl. auch Pepper)
  • Passwort-Hashfunktionen
    die im Vergleich zu den auf Effizienz optimierten Funktionen wie etwa SHA-2 wesentlich mehr Aufwand je Hash-Berechnung erfordern, um Angriffe zu verlangsamen.

Salt

Es ist gängige Praxis, Passwörter mit Salts zu versehen.

  • Ein Passwort wird nicht mehr direkt gehasht, sondern es wird zusammen mit dem Salt in die Hashfunktion eingegeben.
  • Das Salt wird in der Regel für jeden Benutzer bei dessen Kontoerstellung zufällig erzeugt und zusammen mit dem Hashwert und den übrigen Benutzerdaten in der Datenbank gespeichert.

Bereits die Verwendung eines konstanten (für alle Benutzer gleichen) Salts würde es verhindern, 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.

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.

  • Da aber für jeden Benutzer ein eigener Salt erzeugt wird, ist ein aus Probepasswort und Salt berechneter Hashwert nur noch für diesen Benutzer gültig.
  • Jedes Probepasswort muss für jeden Benutzer erneut gehasht werden.

Pepper

Um Wörterbuch- und Brute-Force-Angriffe weiter zu erschweren, kann das Passwort zusätzlich zum Salt mit einer beim Einrichten des Servers gewählten und geheimgehaltenen Zeichenfolge kombiniert werden, um den Hashwert zu berechnen.

  • Diese Zeichenfolge wird Pepper (Pfeffer) genannt und ist normalerweise für alle Passwörter auf einem Server gleich.
  • Indem der Pepper für jedes Passwort unterschiedlich gewählt wird, kann die Sicherheit weiter erhöht werden.
  • Der Unterschied zwischen Salt und Pepper ist, dass der Pepper nicht in derselben Datenbank wie der Hashwert gespeichert, sondern an einem anderen und möglichst sicheren Ort hinterlegt wird.
  • 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 ein Wörterbuch kaum 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, da dann die Kollisionsresistenz der Hashfunktion nicht mehr ausschlaggebend für die Sicherheit der Gesamtkonstruktion ist.

Passwort-Hashfunktionen

Es gibt speziell zum Hashen von Passwörtern entwickelte Hashfunktionen, z. B. bcrypt, scrypt und Argon2.

  • Diese erlauben 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 erwarteten 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

Weblinks

  1. https://de.wikipedia.org/wiki/Salt_(Kryptologie)
  2. heise.de – Passwörter unknackbar speichern
  3. Wie man mit Pfeffer den Fisch versalzt – Tutorial über das sichere Speichern von Passwörtern.
  4. Mögliche Passwort-Hashes