Bei der heutigen Anmeldung an Windows Azure bekam ein Kollege nun folgende Meldung, die ihn etwas verwunderte:

Wir dürfen also als Passwort nur 16 Zeichen eingeben – und wenn unser ursprünglich gewähltes Passwort länger ist, sollen wir einfach die ersten 16 Zeichen eingeben … das passt dann schon.

Das wirft erst mal die Frage auf, wie mit den ersten 16 Zeichen eine Passwort-Validierung durchgeführt werden kann, wenn das Passwort als “Salted Hash” in der Authentisierungsdatenbank liegt? Wir haben ja gelernt: man speichert keine Passwörter ab, sondern nur einen Hash-Wert, nachdem das Passwort mit einem anderen bekannten Text verknüpft wurde (eben dem “Salt”, welches für jeden Wert wieder anders sein sollte) … wir wollen ja nicht, dass aus der Passwort-Datenbank der Datenbank-Administrator sämtliche Passwörter rekonstruieren kann.

Die Antwort liefert folgender Eintrag in der Support-Datenbank: “Getting error Microsoft account passwords can contain up to 16 characters?”:

“Your password has not been shortened.  Windows Live ID passwords have always been limited to 16 characters.  What has changed is the login page now gives you immediate feedback to ensure you understand your password is not more than 16 characters.”

Was bedeutet das nun für die Sicherheit von Windows-Live-IDs?

1. Die Sicherheit von Passwörtern für Windows-Live-IDs ist auf 16 Zeichen beschränkt.
2. Die Passwörter “können” als “Salted Hash” gespeichert werden und trotzdem reichen die ersten 16 Zeichen aus, um das Passwort zu prüfen – das Kürzen auf 16 Zeichen wurde ja vor der ursprünglichen Hash-Berechnung durchgeführt.
3. Die Menge an effektiv genutzten Hash-Ergebnissen bezogen auf die Menge der potentiellen Passwörter ist extrem reduziert. Hash-Algorithmen sind keine Transformationen, die eine 1:1-Beziehung zwischen Eingabe und Ausgabe herstellen, sondern eine unendlich große Menge an Eingabe-Werten wird auf eine endliche Menge an Ergebniswerten “projiziert”.
4. Wenn man bedenkt, dass eine der Strategien zur Bildung “unknackbarer” Passwörter die Verwendung von Passphrasen ist (z.B. enthält “Das Passwort ist nicht knackbar, selbst wenn Du dich noch so sehr anstrengst!” bereits 77 Zeichen mit Sonderzeichen, kleinen und großen Buchstaben und ist trotzdem leicht zu merken – einer Brute-Force-Attack hält dieses Passwort aber sehr lange stand), werden von diesen Passphrasen ja auch immer nur die ersten 16 Zeichen verwendet (in diesem Fall also “Das Passwort ist”), was dazu führt, dass sehr viele Passphrasen im Endeffekt das selbe gekürzte Passwort verwenden.

In einer extrem einfachen “Hash”-Funktion (Addition aller Dezimal-Stellen Modulo 100) könnten solch eine Kürzung die Passwörter “1234” und “4321” den selben “Hash”-Wert haben (in diesem Beispiel 10). Wenn ich jetzt das Passwort “12345” ausprobiere, komme ich auf einen anderen Wert (15). Schneide ich aber nach 4 Zeichen das Passwort ab, hat auch “12345” den selben “Hash”-Wert – nämlich 10. Zudem ist die Menge der erzeugbaren “Hash”-Werte eingeschränkt, da der größte effektive Eingangs-Wert 9999 ist – mit dem “Hash”-Wert 36. Einen Hash-Wert 50 kann ich gar nicht mehr erzeugen, da ich mit der Summe von 4 Zeichen diesen Zahlenwert gar nicht mehr erreichen kann. Kürze ich also das Passwort, dann fallen auch eine ganze Menge an möglichen Hash-Werten weg – die Wahrscheinlichkeit steigt also, dass ich den Hash-Wert für ein unbekanntes Passwort erraten kann. In wie weit dieser letzte Punkt für Live-ID relevant ist, hängt von dem verwendeten Algorithmus ab.

Was bedeutet das für mich? Ganz ehrlich: Unverständnis.

Die in dem Forums-Eintrag zur Live-ID gegebene Erklärung ist:

“We are working on increasing the maximum password length. Unfortunately, for historical reasons, the password validation logic is decentralized …”

Das “increasing the maximum password length” macht mich skeptisch, ob das Ergebnis dieser Bemühungen für mich akzeptabel sein wird. Aus meiner Sicht darf es gar keine solche Begrenzung geben: Das Passwort sollte als Hash abgelegt werden und dabei ist die Länge des verwendeten Passworts irrelevant: Wenn wir z.B. SHA-256 als eine einigermaßen sichere Hash-Algorithmus-Familie annehmen, kommen wir konstante 256 Bit für die zu speichernde Struktur (+ Salt). Selbst wenn ich den kompletten Text-Inhalt von Goethes Faust als Passwort verwenden würde – die Berechnung des Hash würde eine Millisekunde länger dauern, das Ergebnis wären aber immer noch 256 Bit.

Immerhin werden die Nutzer von LiveID jetzt ordnungsgemäß auf die stark eingeschränkte Passwort-Sicherheit hingewiesen.