Ein Rezept für sichere Passwörter: Zeichensalat, Salz und Pfeffer

Im letzten Teil unserer Artikelserie zum Thema Passwortverschlüsselung als Reaktion auf das NetzDG haben wir versucht dir näher zu bringen, welche Arten von Verschlüsselung es gibt und was der Unterschied zwischen „Verschlüsselung“ und „Hashing“ ist. Heute beschäftigen wir uns mit dem richtigen Rezept für‘s Hashing – und die Zutaten dazu sind:

Zeichensalat, Salz und Pfeffer.

Das Gold am Ende des Regenbogens

Nachdem wir beim letzten Mal unsere Passwörter durch ein (hoffentlich) kryptografisches Hashverfahren in „Buchstabenbrei“ verwandelt haben, ist ein Problem offen geblieben:

Was passiert, wenn man einfach alle Passwörter vorberechnet?

Nehmen wir an wir wissen, dass bei einer Plattform das unsichere SHA-1 Verfahren zum Einsatz kommt und als einziges Kriterium mindestens 6 Zeichen für Passwort benötigt werden. Mit diesen Voraussetzungen ist es ein leichtes, Hashwerte vorzuberechnen – zum Beispiel:

111111 = 3d4f2bf07dc1be38b20cd6e46949a1071f9d0e3d
111112 = 1f8242ad6335e54948739a4dab0ef7a786222176
111113 = cf501c05d148b9e1f54a97ef1007575b2c43cb68

Diese „Vorberechnung“ von Passwörtern nennt man „Rainbow-Tables“. Diese Art von Angriffe waren besonders zu der Zeit beliebt, als auch noch MD5-Hashes zur Prüfung von Passwörtern verwendet wurden. Aus diesem Grund gibt es in diversen Datenbanken Unmengen an vorberechneten Passwörtern.

Aber zurück zum SHA1-Verfahren: Ein älterer Laptop den ich hier rumstehen habe schafft es, 1.000.000 Passwörter in 0,83 Sekunden zu hashen. Das bedeutet, dass in einer Stunde ca. 4.337.349.397, also über 4 Milliarden Passwortkombinationen berechnet werden können. Genug Speicherplatz vorausgesetzt ist es also ziemlich wahrscheinlich, dass auch dein Passwort sehr schnell gefunden wird.

Das Salz in der Passwortsuppe

Diese Art von Vorberechnung ist natürlich mehr als ein Problem, wenn Passwörter nicht über den Hash herausfindbar sein sollen. Aus diesem Grund kamen kluge Köpfe auf die Idee, etwas „eindeutiges“ in das Passwort mit einzupflechten, um das Passwort eindeutig zu machen. Nehmen wir einmal an, zwei Benutzer registrieren sich zu unterschiedlichen Zeiten mit dem selben Passwort „111111“ und der Registrierungszeitpunkt wird einfach an das Passwort angehangen:

1.) 1111111595408304=df3cc5c72938b96a3a3a508da13b527bc595ae6a
2.) ​​​​​​​1111111595408355=0e37c105ffe409c498723a60754e8978c434e3b9

Trotz Nutzung des selben Passworts werden so zwei vollkommen unterschiedliche Hashwerte generiert. Diesen Vorgang nennt man „salzen“ des Passworts. Der eindeutige Wert, in unserem Fall also die Zeit, wird als „salt“ mit in die Datenbank gespeichert und bei jedem Authentifizierungsversuch an das vom Nutzer eingegebene Passwort angehängt. Da man nicht alle Kombinationen von Passwörtern für jeden Zeitpunkt vorberechnen kann, hat man den Einsatz von Rainbow-Tables somit also praktisch entschärft.

Was aber, wenn jemand durch ein Missgeschick oder einen gezielten Angriff die Datenbank erobert? Sobald der „salt“ des Accounts bekannt wird, könnte man durch ausprobieren ja potentiell wieder das Ursprungspasswort erraten. Zeit, unser Buchstabensüppchen zu verfeinern.

„Aufpeppen“ von Hashes

Da beim Erbeuten der Datenbank der „salt“ bekannt wird, benötigen wir noch eine weitere Komponente, die nicht in der Datenbank liegt. Diese Komponente wird „Pepper“ genannt und ist im Optimalfall eindeutig pro Software-Instanz. Nehmen wir also an, ich habe eine Webanwendung und installiere sie auf zwei Servern, dann sollten jede Anwendung einen unterschiedlichen „Pepper“-Wert generiert haben.

Auch diese können wir wieder einfach in unsere „Passwortsuppe“ einfügen, sodass wir auf beispielhaft auf folgendes Rezept zur Generierung von Hashes kommen:

Hashfunktion(Pepper + Passwort + Salt) = Hash

oder bildhaft mit unserer sha1-Funktion:

sha1(1595409761 + 111111 + 1595408304) = 01c3c4ea0a15f784741900a84b691f07b6db5411

Auf diese Weise ist unser Passwort selbst dann noch deutlich schwieriger zu „erraten“, wenn die Datenbank geleakt ist, weil man zusätzlich auch noch den Pepper vom Applikationsserver benötigt.

Ein Hinweis dazu: In der realen Ausführung sind diese Verfahren natürlich deutlich komplexer und Salt und Pepper deutlich länger. Auch das SHA1-Verfahren sollte man nicht mehr einsetzen und wurde hier nur gewählt, weil der Hashwert vergleichsweise kurz und damit besser mit dem menschlichen Auge vergleichbar ist.

Trotzdem hoffe ich, dass du mit diesem Artikel einen guten Überblick über das Passworthashing erhalten hast und verstehst, warum das Thema mit der „Passwortherausgabe“ beim NetzDG nicht so einfach ist. Voraussetzung dafür ist natürlich, dass der Sicherheitsstandard mit Salt (und unter Umständen auch Pepper) eingehalten werden, was leider immer noch nicht überall der Fall ist.

Zuletzt möchte ich noch einmal ein paar Schwächen des Gesetzes hervorheben, die ganz gezielt mit der Speicherung von Passwörtern zu tun haben:

• Im Gesetz steht „Eine Verschlüsselung der Daten bleibt unberührt“ – genau genommen haben wir aber nun gelernt, dass Passwörter nicht verschlüsselt (Ursprungspasswort kann zurückgeberechnet werden), sondern gehasht (Ursprungspasswort muss „geraten“ werden) werden.
  Hoffen wir einfach mal, dass Hashing gesetzlich als Einwegverschlüsselung interpretiert und zukünftig keine Verschlüsselung von Passwörtern gefordert wird.
• Damit das Passwort effizient „geraten“ werden kann, müssen Salt und Pepper herausgegeben werden. Da der Pepper ALLE Passwörter einer Datenbank betrifft, ist die Sicherheit der kompletten Datenbank ab Bekanntwerden des Peppers beeinträchtigt
• Selbst wenn alle diese Daten an das BKA weitergeleitet werden, ist der Aufwand zum Erraten eines Passwortes mit kryptografischen Hashfunktionen enorm. Zum Vergleich: die SHA1-Funktion, die ich oben verwendet habe berechnet 1 Mio Passwortkombinationen in 0,8 Sekunden. Je nach Hashfunktion kann es sein, dass die Berechnung eines einzigen Passworts bereits 0,8 Sekunden dauert. Das macht beim Login für den User keinen großen Unterschied, beim „Raten“ von Passwörtern ist er aber enorm
• Sofern das Passwort am Ende „erraten“ wurde kann man sich immer noch nicht sicher sein, ob man tatsächlich das Ursprungspasswort, oder (je nach Hashverfahren) vielleicht doch eine Kollision gefunden hat. Der Zweck, das Passwort für weitere Plattformen zu Nutzen wird dadurch also verfehlt