Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

Maximal 16 Zeichen Sicherheit bei Windows Live-Account-Passwörtern

26.09.201208:12 Uhr , Sven Matzen

Die SDX AG verwendet für technische Passwörter (also solche, die nur extrem selten von Menschen verwendet werden) meist eine Kette zufälliger Zeichen, die länger als 20 Zeichen ist, damit erzwungen wird, dass keine LAN Manager Hashes erstellt werden (diese werden per Default nicht mehr erstellt, wenn das Betriebssystem Vista oder höher bzw. Server 2008 oder höher ist[1] – die Regel mehr als 14 Zeichen zu verwenden sollte aus Sicherheitsgründen aber trotzdem eingehalten werden).

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

LogOnScreen

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.

Tags: Cloud

2 Kommentare

26.09.201218:01 Uhr
DanielT

Du hast aber mit 16 zufällig(!) gewählten Zeichen aus einem 100-Zeichen-Raum immer noch über 100 Bit Entropie, das ist mit Brute-Force auch in den nächsten Jahren nicht wirklich zu knacken (ein Petaflop-Rechner würde > 30 Mio. Jahre brauchen).

Viel problematischer sind die Leute, deren Passwort "123456" o.ä. lautet, da hilft auch der schönste salted hash nichts.

Dennoch war das stillschweigende Kürzen auf 16 Zeichen natürlich ziemlich daneben. Wenn sie das aus technischen Gründen vorerst beibehalten müssen, ist es OK, wenn sie es zumindest stark publik machen.

Warum es überhaupt eine Längenbeschränkung geben sollte, ist mir allerdings auch unverständlich. Idealerweise sollte das Passwort doch schon auf Client-Seite gehashed werden (und dann noch einmal mit einem Salt auf Serverseite), sodass es erst gar nicht übertragen wird (Blizzard macht das z.B. so). Das reduziert auch die Angriffsfläche gegen abgehörte Verbindungen oder man-in-the-middle-Attacken. Ist natürlich ärgerlich, dass das wieder nicht ohne JavaScript geht (oder kann HTML5 das?).

27.09.20129:19 Uhr
Sven Erik Matzen

Hallo Daniel.
HTML5 kann das nicht, aber es ist eine "Web Cryptography API" (http://www.w3.org/TR/WebCryptoAPI/) von der W3C in Vorbereitung.
Viele Grüße,
Sven

Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud


Kontakt aufnehmen


Anrufen

Gerne beantworten wir Ihre Fragen in einem persönlichen Gespräch!


Kontakt aufnehmen

Schreiben Sie uns eine E-Mail mit Ihren Fragen und Kommentaren!