Immer wieder hört man von Vorfällen bei denen unzählige Passwörter gestohlen wurden und Nutzer einer Plattform dazu aufgefordert werden, ihre Passwörter zu ändern. Aber warum passiert das eigentlich so häufig? Und wie kann man als Entwickler die Passwörter sicher speichern?
Wer die Lektüre scheut, kann sich auch das zugehörige Video auf YouTube anschauen.
In diesem Artikel beziehen wir uns auf eine imaginäre Website, welche über ein Nutzersystem verfügt. Im Hintergrund werden die Daten der Nutzer in einer nicht näher benannten Datenbank gespeichert.
Klartextspeicherung
Jetzt wollen wir also unsere Nutzer und ihre Login-Daten in unserer Datenbank speichern. Das heißt, wir erstellen für jeden Nutzer einen neuen Eintrag mit ID, Nutzernamen, E-Mail-Adresse und (natürlich) dem Passwort.
Dabei belassen wir das Passwort, wie es von Gott geschaffen wurde: nackt und im Klartext.
Angriffsszenario
Jetzt wird unser Dienst von einem Hacker angegriffen. An dieser Stelle betrachten wir keine Sicherheitslücken, die clientseitig stattfinden könnten, wie beispielsweise SQL Injection. Unser Hacker versucht lediglich Zugriff auf unseren Server bzw. die dahinterstehende Datenbank zu erlangen.
Zufälligerweise kennt der Angreifer den Namen unseres Haustiers, was wir nämlich als Zugangspasswort für die Datenbank gesetzt haben. Und in Nullkommanichts hat der Hacker hat alle Daten unserer Datenbank und damit auch die Passwörter der User. Eventuell sogar Finanzdaten oder Ähnliches.
Evaluierung
Da weiß jeder Laie, dass diese Art der Speicherung von Passwörtern absolut unsicher ist und niemals verwendet werden sollte. Außerdem ist es sinnvoll als Server-Betreiber ein etwas sichereres Passwort zu wählen.
Übrigens gibt es noch sehr viele Websites und Services, die auf diese Weise Passwörter speichern – oder eher: verschenken. Zu erkennen sind sie unter anderem daran, dass sie dir freundlicherweise dein Passwort zuschicken, falls du es vergessen haben solltest! Also: renn, wenn dein Passwort plötzlich in dein Postfach flattert. Und informiert vielleicht netterweise vorher noch den Betreiber der Webseite über das Sicherheitsproblem.
Hashing der Passwörter
Was kann man tun, um ein solches Szenario zu verhindern? Zur Rettung kommen „Hash-Funktionen“. Dazu gehören unter anderem „MD5“, „SHA-256“ oder „SHA-512“, um nur ein paar Beispiele zu nennen. Hash-Funktionen generieren für beliebige Eingabewerte eine Bitfolge, die oftmals in Hexadezimalschreibweise dargestellt wird. Dabei ergibt derselbe Eingabewert immer den exakt gleichen Hash-Wert. Vom Hash-Wert lässt sich jedoch nicht auf die ursprüngliche Eingabe rückschließen; somit sind Hash-Funktionen unumkehrbar.
An dieser Stelle bezeichne ich den Prozess des Hashen gerne inkorrekterweise als Verschlüsseln. Eine Verschlüsselung hat stets die Intention, die Nachricht später auch wieder zu entschlüsseln. Beim Hashen geht es aber gerade darum, die Umkehrung zu verhindern.
Also nehmen wir eine Hash-Funktion — heutzutage zu empfehlen ist mindestens SHA-512, da sie recht lange Hash-Werte erzeugt und damit ziemlich langwierig zu knacken ist.
Mit dieser Hash-Funktion verschlüsseln wir das Passwort, was der Nutzer bei der Registrierung eingibt. In die Datenbank gelangt dann ausschließlich dieser Passwort-Hash; das ursprüngliche Passwort wird nirgendswo gespeichert.
Sobald der Nutzer sich einloggt, wird überprüft, ob der berechnete Hash-Wert des eingegebenen Passworts mit dem Passwort-Hash aus der Datenbank übereinstimmt. Nur wenn dies der Fall ist, hat der Nutzer das richtige Passwort eingegeben.
Nun kommt der gleiche Hacker wieder und da wir das Passwort für den Datenbankzugriff dummerweise immer noch nicht geändert haben, kann er wieder alle Einträge abzweigen. An sich hat der Eindringling jetzt keine Möglichkeiten die Passwörter zu lesen.
Allerdings gibt es Sammlungen voller Hash-Strings und deren ursprünglichen Ausgangswerten. Diese sind auch vielfach als einfach zu bedienende Web-Interfaces anzutreffen. Dort kann man beliebige Hash-Werte eingeben und es wird, wenn gefunden, das Passwort (oder jeglicher anderer Wert), welches dahintersteckt, zurückgegeben.
Diese sogenannten Rainbow Tables existieren insbesondere für MD5 massenhaft. Daher ist MD5 eine besonders schlechte Option für das Hashen von sensiblen Daten wie Passwörtern. Jedoch gibt es auch genügend solcher Tabellen für andere Hash-Funktionen, z.B. die bisher genannten SHA-256 oder SHA-512. Vor allem die (leider) häufigsten Passwörter mit Kultstatus, wie „123456“, „password“ oder „qwerty“, sind bei keiner Hash-Funktion ein Problem — bzw. in Anbetracht der Sicherheit ein enorm großes Problem.
Gesalzene Passwort-Hashes
Die Lösung zur sicheren Speicherung von Passwörtern lautet „Salting“ (zu Deutsch „salzen“). Dieser Begriff hat nur entfernt etwas mit dem allseits bekannten Mineral, was für kulinarische Ergüsse sorgt, zu tun. Ähnlich wie beim Natriumchlorid wird auch beim Salting etwas hinzugefügt.
Nur ist es nicht ein beliebiges Gericht, das versalzen wird, sondern das Passwort: Vor dem Anwenden der Hash-Funktion fügt man etwas dem eingegebenen Passwort hinzu. Unter anderem kann das die E-Mail-Adresse sein, oder aber ein „zufällig“ generierter String.
Die Sicherheit von Salting basiert grundlegend auf der Länge des hinzugefügten Strings. Daher ist es nicht zu empfehlen, die in der Realität sehr variabel langen E-Mail-Adressen zu nehmen.
Der hinzugefügte String (= Salt/Salz) sorgt dafür, dass selbst die simplen und frequentierten Passwörter („123456“ etc.) einzigartig in ihren Hashes sind, da das Salt einzigartig für jeden Nutzer generiert wird.
Da helfen dann auch keine Rainbow-Tables mehr. Also: Mission accomplished, unsere Passwörter sind sicher gespeichert!
Praxisbeispiel
Praktisch würde eine Registrierung mit Salting in etwa so aussehen:
- Der Nutzer registriert sich mit seinem Passwort sowie seiner E-Mail-Adresse.
- Diese Eingabe wird an den Server übermittelt.
- Der Server fügt dem Passwort die E-Mail-Adresse an.
- Dieser Text wird mit einer Hash-Funktion verschlüsselt, sagen wir mal SHA-512.
- Der Server speichert das verschlüsselte Passwort, Nutzernamen und E-Mail-Adresse in einer Datenbank.
Ähnlich läuft dann auch jeder nachfolgende Login ab:
- Der Nutzer loggt sich wie immer mit seiner E-Mail-Adresse und seinem Passwort ein.
- Dem eingegebenen Passwort wird die E-Mail-Adresse angehangen und das ganze wird wieder mit der gleichen Hash-Funktion verschlüsselt.
- Der Server ruft das verschlüsselte Passwort aus der Datenbank ab.
- Es wird überprüft, ob das verschlüsselte Passwort aus der Datenbank mit dem verschlüsselten eingegebenen Passwort übereinstimmt. Ist dies der Fall, wird der Nutzer eingeloggt.
Ausblick & Quantencomputing
Derzeit ist die beschriebene Methode des Passwort-Hashing mit Salt also so gut wie unknackbar und alle Services, die mit Passwörtern oder sensiblen Nutzerdaten zu tun haben, sollten eine Art von dieser Verschlüsselung nutzen.
Allerdings könnte es mit zunehmender Effizienz und Popularität von Quantencomputern gefährlich für diese Passwörter werden. Denn gut optimierte Quantencomputer sind um ein Vielfaches schneller als herkömmliche Rechner, wenn es um das Knacken von Hash-Werten geht. Daher sollten wir uns schon bald Gedanken über eine neue Methode der Passwort-Speicherung machen.
Schluss
TL;DR: Keine Passwörter im Klartext speichern. Langen, für jeden Nutzer einzigartigen String an Passwort anhängen, dann mit sicherer Hash-Funktion verschlüsseln.
