Hashes & Salts

Wie man zu einem Blogpost kommt …

Der Grund für diesen Post ist (wieder einmal) ein Hack. Dieses Mal hat es Canva erwischt, ein australisches Startup, mit dem sich einfach Grafiken & Text mischen lassen. Ein Hacker hat bis etwa Mitte Mai ca. 139 Millionen Datensätze von Benutzern erbeutet. Immerhin wurden die Nutzer benachrichtigt.

Auch im Bildungsbereich ist Canva relativ verbreitet, da sich damit relativ einfach grafisch gute Ergebnisse erzielen lassen. Der letzte Satz hat wohl Sascha ins Grübeln gebracht, als er mich auf Twitter gestern gefragt hat:

Man soll sich aber keine Sorgen machen weil die Passwörter “…mit bcrypt und individuellem salt gehasht” wurden. Ist das wirklich safe @DerLinkshaender?

Zuerst einmal Danke für das Vertrauen in meine technische Kompetenz! Ich habe dann angeboten, etwas zu diesem Thema zu bloggen, wenn Begriffe wie Hashes, Salting, Rainbow Tables nach Bahnhof klingen.

Willkommen zum Ergebnis und ich hoffe, die Erklärungen sind verständlich. Lasst uns starten…

Passwörter, Hashes & Salts – ohne Jargon 😉

Wozu überhaupt Passwörter?

Passwörter sind ein möglicher Ansatz, den Zugang zu einem geschützten System zu validieren. Ohne Schlüssel (hier das Kennwort) geht gar nichts – das alte “Sesam, öffne Dich!”

Fangen wir einfach an. Wie funktioniert ein Login in der einfachsten möglichen Form?

1. Nutzer will sich am System anmelden
2. System verlangt Eingabe des Kennworts
3. Nutzer gibt eine Zeichenkette ein
4. System vergleicht Eingabe von Nutzer mit dem gespeicherten Kennwort
5. Abhängig vom Ausgang des Vergleichs wird der Zugang gewährt oder nicht

Warum sollte ich so keine Passwort-Abfrage bauen? Die Kennwörter müssen irgendwo im System abgelegt werden, zum Beispiel in einer Datenbank bei den anderen Informationen eines Nutzerkontos. Bricht nun jemand in das System ein und klaut die Datenbank, hat der Eindringling nicht nur die persönlichen Daten, sondern auch alle Passwörter im Klartext.
Gar nicht gut! 😱

Unsere Password-Tabelle sieht also jetzt so aus:

Auftritt Hashes

Wie bekommen wir nun die Passwörter sicher? Vorab: nein, eine verschlüsselte Speicherung ist nicht so sicher, weil die Passwörter vor dem Vergleich ja wieder entschlüsselt werden müssten. Was tatsächlich gemacht wird, ist die Speicherung der Hashes der Passwörter. Was ist dass denn? Wie soll ich das denn im Unterricht den Schülerinnen und Schülern erklären?

Resteverwertung ;-)

Ein ganz einfaches Beispiel für eine Hashfunktion ist der Divisionsrest (modulo-Operation). Dazu wird der Divisionsrest als Ergebnis der Hashfunktion verwendet:

• 6 mod 11 => 6
• 60 mod 11 => 5 (11 * 5 = 55, daher bleibt ein Rest von 5)

Dieses Beispiel zeigt auch gleich die Herausforderungen für eine Hashfunktion. Was passiert, wenn wir die Funktion für die Zahl 17 berechnen? Das Ergebnis ist ebenfalls 6! 😱
Das wird als “Hashkollision” bezeichnet und sollte nicht vorkommen, wenn Hashfunktionen für kryptografische Zwecke benutzt werden. Wenn eine andere Zeichenkette den gleichen Hashwert liefert wie mein Password, beruhigt mich das nicht gerade …

Das “Geburtstagsproblem” ist auch eine Art Hashkollision: die Wahrscheinlichkeit, dass jemand am gleichen Tag wie ich Geburtstag hat (ohne Berücksichtigung des Jahres), beträgt bei nur 23 Personen bereits über 50% (der Beweis wird den mitlesenden Mathematik-LuL zur Übung überlassen 😉).

Kryptographische Hashfunktionen

Für den Einsatz im Bereich der Passwörter/Kryptographie werden noch einige andere Anforderungen an Hashfunktionen gestellt:

• Auch eine nur sehr kleine Veränderung des Eingangswertes (1 eiziges Bit) sollte eine Veränderung des Hashwertes (viele Bits im Hashwert) verursachen.
• Der berechnete Hashwert sollte immer eine gleiche Länge haben (bei SHA256 z.B. 256 Bits).
• Jeder mögliche Hashwert soll auch tatsächlich vorkommen
• Performance-Vorteile für Hardware-Implementierungen und andere Programmiersprachen sollen gering ausfallen, da solche Vorteile einem Angriff zugutekommen.
• Der Speicherbedarf des Hashes sollte kleiner sein als der des Eingangswertes (Hash von einer langen Zeichenkette soll kürzer sein als die Zeichenkette, ein Hash einer sehr kurzen Zeichenkette soll aber auch einen Hash der definierten Länge liefern).

Was aber mit die wichtigste Anforderung ist: eine kryptographische Hashfunktion ist eine mathematische “EInbahnstrasse”, d.h. es ist enorm schwer bis unmöglich, aus dem Hashwert auf die Ausgangsdaten zurück zu rechnen. Wie oben: wenn ich den Hashwert 6 haben, kann die Eingangszahl 6 sein, oder 17, oder 28 …

Aber genug der Theorie, zu Hashfunktionen gibt es Hunderte gute Einführungen im Web.

Warum Hashes auch nicht die Lösung sind

So, jetzt haben wir eine Hashfunktion. Ich verwende für die folgenden Beispiele den Algorithmus SHA256 und falls Sie selbst Hashes berechnen wollen: es gibt unter der Adresse https://hashgenerator.de/ einen Online-Generator für Hashes.

Nun machen wir folgendes: wird ein Benutzerkonto angelegt, wird das vom Nutzer vergebene Passwort sofort der Hashfunktion übergeben und es wird der Hash gespeichert. Beispiel:

Password: GanzGeheim
Hash: d5517c76940d74bf03f729fe66312c5322ce00753cec38a309d8c8c934b38e11

Bei der Anmeldung wird aus der Eingabe des Passwortes ebenfalls der Hashwert berechnet und es werden nur die beiden Hashwerte veglichen. Unsere Password-Tabelle sieht also jetzt so aus. Damit haben wir keine Klartext-Passwörter mehr und aus dem Hashwert ist das auch nicht rückführbar.

Sind wir damit “safe”, wenn der Hacker die Datenbank mit den Nutzerkonten klaut? Sie ahnen es schon: Nein, sind wir nicht. Hier kommen die “dictionary attacks” (Wörterbuchangriffe) ins Spiel und vorberechnete Hashtabellen (hash table, rainbow tables): um an die Passwörter zu kommen, gibt es verschiedene Möglichkeiten. Die eine ist es, jedes mögliche Passwort aus dem Zeichenvorrat zu erzeugen und dann den Hashwert zu berechnen, die andere, die häufigsten Wörter anhand eines Wörterbuchs oder einer Liste häufiger Passwörter zu berechnen. Dann muss ich nur noch den geklauten Hashwert in der ausgerechneten Liste finden und kann dahinter das Passwort ablesen.

Das (für die Nutzer schlechte) Ergebnis zeigt sich, wenn wir nochmal die Password-Tabelle ansehen:

In dem Moment, wo ich das Passwort für den Nutzer franz.testhuber gefunden habe, habe ich das auch für das Nutzerkonto von user.4711. Schließlich erzeugt die Hashfunktion ja entsprechend ihrer Definition für die gleiche Eingabe den gleichen Hashwert. Wir brauchen also zusätzlich zu unserer Hashfunktion etwas, das bei gleichen Kennwörtern dennoch andere Codes erzeugt. Nun wird es endlich salzig …

Cum grano salis – mit einem Körnchen Salz

Ein «Salt» ist in der Kryptographie genau das, ein kleines Körnchen Gewürz mit großer Wirkung. Für jedes Nutzerkonto erzeugen wir nun eine zufällige Zeichenkette und fügen diese mit dem Passwort zusammen. Dann wird der Hashwert für diese Kombination erzeugt. Auch bei einem gleichen Passwort haben wir durch das individuelle Salt immer eine andere Zeichenkette und damit einen anderen Hashwert! Den Hash speichern wir in der Tabelle der Nutzerdaten.

Es mag nicht intuitiv klingen, aber es reicht völlig aus, den Salt unverschlüsselt zu speichern. Wir müssen beim Vergleich mit der Eingabe beim Login ja auch den Salt mit dem Passwort kombinieren. Der Hacker hat keinen Nutzen, da zwei verschiedene Hashwerte erzeugt werden und es müsste jetzt für jeden möglichen Werte eines Salts eine Tabelle mit den Hashes aller möglichen Kennwörter erzeugt werden. Das wird sehr schnell unwirtschaftlich bzw. nicht mehr speicherbar oder handhabbar.

Das Ergebnis zeigt unsere neue Tabelle, auch bei gleichem Passwort haben wir zwei verschiedene Hashwerte für die Konten von franz.testhuber und user.4711:

Dazu kommt, dass für solche Zwecke die Hashfunktion auch so gewählt wird, dass sie für Einbruchsversuche “teuer” wird, also einen hohen Zeit- oder Rechenaufwand erfordert. Für das Login ist es unerheblich, ob die Berechnung des Hashes 1 Mikrosekunde oder 1 Millisekunde dauert. Für Hacker ist dieser Faktor 1000 vielleicht der Unterscheid zwischen “machbar” und “vergiss es”, weil sich in der gleichen Zeit nur ein Tausendstel der Hashwerte berechnen lässt.

Eine solche Funktion, die gezielt für das Hashen und Speichern von Passwörtern entwickelt wurde, ist «bcrypt». Entwickelt von Niels Provos und David Mazières wurde bcryt 1999 vorgestellt. Wer mehr wissen möchte (Vorsicht, Fachjargon) kann hier nachlesen.

Alle Klarheiten beseitigt?

Kommen wir zum Schluss zurück zu Canva. Ja, grundsätzlich hat das Team von Canva also Recht, wenn Sie sagen, dass die Passwörter von niemandem einsehbar sind, wenn alles richtig implementiert wurde. Dennoch an dieser Stelle ein Hinweis:

Wer mal testen möchte, ob seine Mailadresse oder sein Password in einer der im Internet kursierenden Dateien mit gehackten Daten auftaucht, kann hier nachgucken: https://haveibeenpwned.com/.

Ich hoffe, dieser Artikel konnte das grundlegende Prinzip hinter Hashes und Salts für Passwörter verdeutlichen. Wer noch Fragen hat oder Vorschläge für Erweiterungen oder Änderungen im Text, kann mich im Fediverse erreichen.