© Vitaliy Vodolazskyy, 123RF

Als Gründer und wohlwollender Diktator eines Business-Netzwerkes beschreibt Autor Stefan Wintermeyer, wie komplex das Speichern von Passwörtern in landläufigen Webapplikationen sein kann.

Mitte Juni 2019 speicherte unser quelloffenes Business-Netzwerk Vutuv.de [1], das mit dem Motto “Fast, secure and less annoying” wirbt, über 20000 Userdaten. Kann ein einfacher Benutzer aber Geschwindigkeitswerte noch recht einfach nachvollziehen, wird das beim Thema Sicherheit schon komplizierter.

Bei Closed-Source-Applikationen wie Linked.in oder Xing müssen sich Dritte in Sachen Security in der Regel auf die Aussagen der Betreiber verlassen. Da sie keine Einsicht in die Netzwerke haben, wissen sie nicht sicher, wie diese ihre Passwörter schützen. Und wenn sie es erfahren, ist das Kind mitunter schon in den Brunnen gefallen. So passiert etwa im Jahr 2012, als Linked.in geschätzt 6,5 Millionen verschlüsselter Passwörter verlor. Eventuell waren es mehr, genaue Zahlen nannte das Unternehmen nicht. Aber 2016 bot ein Hacker dann die Kundendaten von 117 Millionen Linked.in-Nutzern zum Kauf an [2].

Alle sozialen Netzwerke speichern naturgemäß persönliche Daten und müssen sie absichern. Open-Source-Lösungen (siehe Kasten “Open-Source-Infra”) gehen aber mit ihren Security-Ansätzen meist offener um. Damit helfen sie nicht nur anderen Projekten und Firmen.

Von allen gespeicherten Daten bilden die Passwörter der Anwender dabei ein besonders attraktives Angriffsziel. Ein Grund: Viele Anwender benutzen ein Passwort mehrfach. Hat ein Angreifer es gefunden oder geknackt, kann er es nicht nur bei dem bereits angegriffenen, sondern oft auch bei anderen Diensten ausnutzen. Ein zweiter: Viele Menschen wählen zu einfache Passwörter.

Passwortfrei ist passé

Mit diesem Wissen im Hinterkopf verzichteten wir in der ersten Version von Vutuv ganz auf User-Passwörter. Beim Einloggen musste der Besucher nur die E-Mail-Adresse eingeben und bekam bei jedem Login-Vorgang einen neu erzeugten Magic Link geschickt, um sich ganz ohne Passwort anzumelden.

Ein wenig Stolz auf unsere sichere Magic-Link-Lösung warteten wir nach dem Start der Plattform auf Lob aus der Community. Das aber blieb aus. Stattdessen kamen Support-Anfragen: Wo man denn das Passwort eingeben könne? Und wie man das Passwort überhaupt setzen könne? Auch die Antwort, dass Vutuv kein Passwort benötige, rang keinem der User ein Kompliment ab.

Doch wir lernten aus dieser Erfahrung: Für Enduser ist es völlig normal, sich auf einer Webseite mit einem irgendwie gearteten Accountnamen und einem Passwort einzuloggen. Sie sind es gewohnt, per E-Mail notfalls vergessene Passwörter zurückzusetzen.

Extrem ungewohnt scheint es hingegen, sich per Magic Link ganz ohne Passwort anzumelden. Für 99 Prozent all unserer Nutzer erwies sich das als nicht intuitiv und damit am Zielpublikum vorbei entwickelt. Am Ende mussten wir der Wahrheit ins Auge schauen. Anfang 2019 entschieden wir uns dazu, eine neue Version 2.0 zu entwickeln, die unter anderem ein klassisches Passwort zum Einloggen braucht [1].

Zweiter Versuch

In der Version 2.0 ging es primär darum, die mit dem Phoenix-Framework gebaute Applikation neu zu strukturieren und mit einer von den Usern vermissten Blog-Post-Funktion zu versehen.

Für die Passwort-Funktionalität haben wir das Rad nicht neu erfunden, sondern diese mit der Phauxth-Bibliothek [9] realisiert. Typisch Open Source: Da wir besondere Anforderungen an das System haben, entstand schnell ein reger Austausch mit dem Bibliotheken-Erfinder David Whitlock aus Thailand. David arbeitet mittlerweile im Vutuv-Core-Team und Vollzeit an der Version 2.0.

Das Worst-Case-Szenario für jede Webapplikation ist aber ein komplett gekaperter Server. Ein Angreifer hätte dann vollen Zugriff auf die Datenbank und alle Konfigurationsdateien auf dem Server. Den Source Code der Applikation hätte er sich wahrscheinlich schon im Vorfeld aus dem öffentlichen Github-Repository [1] gezogen und ihn studiert. Wer diesen Angriffsvektor abdeckt, ist auch bei allen anderen Angriffen auf der sicheren Seite.

Brutal einfach

Der einfachste Angriff ist übrigens eine Wörterbuchattacke, bei der Angreifer populäre Passwörter per Brute Force ausprobieren. Das erfordert nicht mal einen Einbruch in das Zielsystem. Allerdings benötigt der Angreifer dafür einen Accountnamen und dessen Besitzer muss ein schwaches Passwort verwenden (dazu später mehr).

Um so eine Brute-Force-Attacke zu behindern, verwendet Vutuv ein Anmeldelimit. Nach drei Fehlversuchen muss ein User ein paar Minuten bis zum nächsten Versuch warten. Nach weiteren Fehlversuchen wächst die Pause und das System triggert einen internen Alarm.

Heute sichert (hoffentlich!) kein Mensch mehr Passwörter im Klartext in der Datenbank. Denn so erhält ein Angreifer Zugriff auf alle gespeicherten Passwörter. Stattdessen erzeugt die Applikation von einem Passwort einen irgendwie gearteten Hash und speichert diesen ab.

Hash statt Passwort

Das folgende Beispiel geht zunächst vom Message-Digest-Algorithmus 5 (MD5) aus. Der gilt heute als für Passwörter unsicher. Gibt ein Nutzer das Passwort »Banane« ein, erzeugt die Applikation daraus den MD5-Hash »f6ae02c12ed752bcdf92060492cf6572« und speichert ihn in der Datenbank ab.

Loggt sich ein User mit dem Passwort »Banane« ein, reicht das Programm nicht dieses Passwort, sondern den Hashwert des Passworts zum Vergleich an die Datenbank weiter. Ein Angreifer hätte also eine Menge unbrauchbarer Hashes, denn aus dem Hash lässt sich das Passwort üblicherweise nicht zurückdekodieren.

Findige Hacker haben sich vor einigen Jahren gedacht, dass dies auch gar nicht nötig sei. Man könnte ja einfach mittels Brute Force eine Tabelle mit den Hashes aller möglichen Passwort-Kombinationen erzeugen. Mit dieser so genannten Rainbow-Table ließe sich dann leicht das zu einem Hash passende Passwort auslesen. Beim MD5-Beispiel »f6ae02c12ed752bcdf92060492cf6572« reicht sogar schon die Eingabe dieses Strings in Google – und die Suchmaschine gibt dort Links zu fertigen Rainbow-Tables mit der Lösung aus (Abbildung 1).

Abbildung 1: MD5-Hashes lassen sich mitunter recht einfach wieder in die Originalpasswörter übersetzen.

Salz dazu

Als ersten Schritt bietet es sich an, das ursprüngliche Passwort um ein zusätzliches Passwort zu erweitern, das nur der Server kennt, ein so genanntes Salt. Speichern unsere Entwickler also auf dem Server ein Salt mit dem Wert »fasiurw24089sdau« ab und ergänzen dieses um das unsichere Benutzerpasswort »Banane«, kommt als Ergebnis ein sicheres Passwort heraus, das in keiner bereits existierenden Rainbow-Table steht.

Mehr salzen

Klingt nach einer guten Lösung. Doch im Worst Case müssen Seitenbetreiber davon ausgehen, dass ein Angreifer auch Zugriff auf dieses Salt hat. Er oder sie hätte dann nicht nur einen Datenbank-Dump, sondern auch eine Kopie der kompletten Konfiguration gestohlen. Damit ist das Salt bekannt. Da MD5 heute keine echte CPU-Last mehr erzeugt, könnte der Angreifer sich eine neue Rainbow-Table mit diesem Salt erzeugen. Spielt Geld keine Rolle, erledigt er das mit einem Cluster auf AWS in kurzer Zeit.

Ein einzelner Salt-Wert für die komplette Applikation gilt also heute auch nicht mehr als sicher. Der nächste Schritt besteht darin, ein zufälliges Salt für jeden einzelnen Account zu generieren und zusätzlich zum Hash in der Datenbank abzuspeichern. Das legt die Hürde schon sehr viel höher. Ein Angreifer müsste für jeden Account die komplette Rainbow-Table berechnen. Allerdings wäre das beim MD5-Algorithmus und mit einem hohen Budget immer noch eine überwindbare Hürde.

Komplette Rainbow-Tables zu erzeugen, das klappt nur dann kostengünstig und schnell, wenn die kryptografische Hashfunktion wenig Hardware-Ressourcen (CPU und Speicher) erfordert. Bei MD5 ist das aus heutiger Sicht geradezu lächerlich wenig. Deshalb gehen Brute-Force-Angriffe alle möglichen Passwortkombinationen durch.

Das Ziel ist es, einen Hash zu erzeugen, der bei seiner Generation möglichst viele Rechner-Ressourcen bindet, ohne dabei natürlich in ein anderes Extrem abzugleiten. Es ergibt auch keinen Sinn, beim Einloggen erst mal eine Minute warten zu müssen, bis der Server den Hash des eingegebenen Passworts generiert und mit der Datenbank abgeglichen hat.

2015 endete die letzte Password Hashing Competition (PHC, [10]). Entwickler verglichen in einem offenen Wettbewerb 24 verschiedene Hashing-Algorithmen miteinander. Der Gewinner dieses Wettbewerbs war das von Alex Biryukov, Daniel Dinu und Dmitry Khovratovich von der Universität Luxemburg entwickelte Argon2 [11]. Bei Argon2 lassen sich sowohl die CPU- als auch die RAM-Last definieren. Bei Vutuv ab der Version 2 stiegen wir deshalb auf Argon2 um, das ein zufälliges 16-Byte-Salt benutzt.

Der Schritt stellt also sicher, dass Angreifer keine kompletten Rainbow-Tables erzeugen. Das ist allerdings erst die halbe Miete. Dummerweise tendieren Internetuser dazu, sehr einfache und oft die gleichen Passwörter zu verwenden. Beispiele gefällig? Abbildung 2 zeigt die zehn 2018 weltweit am häufigsten verwendeten Passwörter.

Abbildung 2: Die zehn am häufigsten genutzten Passwörter.

Wer sich jetzt eine Liste der 1000 oder gar 10000 beliebtesten Passwörter ergoogelt und sie benutzt, um eine minimale Rainbow-Tabelle zu erzeugen, der kann damit zwar nicht alle Passwörter knacken, aber bereits viele.

Um Vutuv-User vor diesem Angriff zu schützen, setzen wir in Version 2 auf die Datenbank https://haveibeenpwned.com. In ihr finden sich Hashes von 551509767 bereits an anderer Stelle geknackten Accounts. Wer jetzt ein dort bereits geknacktes Passwort benutzt, bekommt von unserem Login-Service eine Warnung.

So stellen wir sicher, dass ein normaler Benutzer des Systems, der sich keine Gedanken über die Sicherheit von Passwörtern macht, kein wirklich einfach zu knackendes Passwort benutzt. Allerdings stellen wir dem Enduser frei, diese Warnung zu ignorieren.

Das große Risiko besteht aber weiterhin in den immer schneller werdenden Computern. Selbst wenn heute ein Angreifer keine komplette Rainbow-Tabelle erzeugt, kann er dies eventuell in 10 oder 50 Jahren machen. Aus diesem Grund empfehle ich jedem Internetnutzer, einen Passwortmanager einzusetzen, der auf jeder Webseite ein neues, zufälliges und einmaliges Passwort erzeugt.

Website-Betreiber müssen immer davon ausgehen, dass ein Account auf irgendeiner Seite einmal gehackt wird. Dann wollen sie sichergehen, dass dieses Passwort auf keiner anderen Seite funktioniert. Das klappt praktisch nur, wenn die Nutzer einen Passwortmanager einsetzen.

Zwei-Faktor-Authentifizierung

Wer einen Account zeitgemäß absichern will, nutzt eine Zwei-Faktor-Authentifizierung (2FA). Dabei erfragt die Webanwendung zusätzlich zum Usernamen und dem Passwort noch einen Einmalschlüssel. In den meisten Fällen werden diese Einmalschlüssel von Handy-Applikationen wie dem Google Authenticator oder von spezieller Hardware wie dem Yubikey [12] erzeugt. Nutzer dürfen aber auch eine Liste von Einmalschlüsseln ausdrucken und diese nach dem Einsatz per Hand mit dem Kuli durchstreichen. Aber: Einen Einmalschlüssel per SMS vom Server aus zu senden, gilt auch nicht mehr als ausreichend sicher.