Warum Passwörter bei Fonic vermutlich nicht sicher sind

Was bisher geschah

Seit ein paar Jahren bin ich Kunde bei Fonic und hatte bis vor einigen Wochen keine Probleme mit ihren Diensten oder ihrem Service. Bis vor einigen Wochen. Die Details sind hier nicht weiter wichtig; mir wurden im Zusammenhang mit mobilem Internet viel zu hohe Kosten berechnet, welche mittlerweile mit Hilfe des Social Media-Teams (welches im Gegensatz zum regulären Support-Team sehr bemüht wirkt) zurücküberwiesen wurden. Das eigentliche Problem wurde allerdings immer noch nicht gelöst. Naja.

Bevor mir (vorerst) geholfen wurde, ergab sich folgende Konversation auf Twitter:

Screenshot 2014-06-10 07.54.20

Normalerweise wird einem auf jeder Internetseite versichert, dass Mitarbeiter (aus guten Gründen!) niemals nach dem Passwort oder Teilen davon fragen werden, und Fonic macht einfach genau das. What the…? Viel größer wird das Erstaunen, wenn man sich einmal kurz überlegt, was für Implikationen es auf, öhm, informatischer Seite hat. Und da ich Informatiker bin und die meisten von euch nicht, erkläre ich euch jetzt was ich meine.

Philipp, wie läuft das denn normalerweise mit den Passwörtern?

Um zu verstehen, warum Fonic vermutlich (vermutlich!) auf die Sicherheit der Nutzerpasswörter scheißt, braucht es zumindest ein wenig Hintergrundwissen; und zwar über (kryptographische) Hashfunktionen.

Normalerweise speichert kein Dienst eure Passwörter direkt in ihren Datenbanken, sondern wendet vorher eine kryptographische Hashfunktion darauf an. Eine solche Funktion berechnet praktisch einen eindeutigen Fingerabdruck des Passworts, und zwar so, dass der Fingerabdruck (und die Hashfunktion) einige wichtige Eigenschaften erfüllen. Beispielsweise ist der (SHA256-)Hashwert des möglichen Passworts

"hallo_welt"

die 256 bit lange Zeichenkette

"1612877a63abdb7344294950142c3b6c290bb1fae63132b924f24d10bcb8bbc9"

Wie der SHA256-Algorithmus darauf kommt, ist an dieser Stelle nicht wichtig und kann hier nachgelesen. Wichtig ist, was der Algorithmus und der resultierende Hashwert für Eigenschaften haben. Dafür stellt man sich den Algorithmus praktischerweise als Blackbox vor, in die irgendwas eingegeben wird und die danach irgendwas ausgibt.
Dann ergeben sich folgende (gewünschte) Eigenschaften:

  1. Einwegfunktion: Die Box soll für jeden Eingabewert schnell eine Ausgabe bestimmen können, allerdings soll die Umkehrung (praktisch) unmöglich sein. Das bedeutet, dass es nur den Bruchteil einer Sekunde dauert, den Hashwert für ein Passwort zu berechnen, aber es nicht möglich ist, nur von dem Hashwert auf das Passwort zu schließen.

  2. Lawineneffekt: Um o.g. Eigenschaft zu gewährleisten, ist der Lawineneffekt gewünscht: Wenn sich nur eine einzige Stelle in der Eingabe ändert, sollen sich möglichst viele Stellen in der Ausgabe ändern. Hashen wir beispielsweise die Zeichenkette „hallo_welt!“ (anstatt „hallo_welt“), ergibt sich mit „454372aaf31e4176fd5ab5496689284ef8cfbe8eb4bfd5ef5bff64780d762371“ ein komplett anderer Hashwert als zuvor. Diese Eigenschaft ist wichtig um zu verhindern, dass sich ein Angreifer der den Hashwert kennt langsam dem richtigen Passwort annähert. Angenommen, unser Passwort lautet „abd“ mit dem Hashwert „42b“ und unsere Hashfunktion hat keinen Lawineneffekt, dann wüsste ein Angreifer der über unseren Passworthash „42b“ verfügt, dass alle Passwörter die er ausprobiert und deren Hashwert nahe „42b“ liegen, ebenfalls nahe am Originalpasswort liegen müssen. Wenn er also beispielsweise „abc“ hasht und als Ergebnis „42a“ bekommt weiß er, dass er das richtige Passwort fast erraten hat und nur noch kleine Änderungen vornehmen muss.

  3. Kollisionsresistenz: Die Wahrscheinlichkeit, dass zwei unterschiedliche Eingaben dieselbe Ausgabe erzeugen soll sehr gering sein. Die Anzahl möglicher Ausgaben des SHA256-Algorithmus ist 2^{256} \approx 1.6 \cdot 10^{77} und somit riesig. Das ist eine Zahl mit 78 Stellen. Es ist also sehr, sehr unwahrscheinlich, zu einem gegebenen Passwort ein zweites zu finden, welches den gleichen Hashwert besitzt.

  4. Determinismus: Für gleiche Eingabewerte gibt es immer gleiche Ausgabewerte. Jedes Passwort hat also immer genau einen Hashwert.

Warum ist das jetzt wichtig für Passwörter?

Langsam wird’s interessant. Wie gesagt; bevor ein Passwort in einer Datenbank gespeichert wird, wird eine Hashfunktion mit oben genannten Eigenschaften darauf angewandt. Da unsere Hashfunktion eine Einwegfunktion ist (Eigenschaft 1), weiß niemand der Zugriff auf die Datenbank hat, was euer Passwort ist. Jedes Mal, wenn ihr euch mit eurem Passwort einloggt, wird euer Passwort gehasht und mit dem in der DB gespeicherten Hashwert verglichen. Stimmen die beiden überein, werdet ihr erfolgreich eingeloggt (Eigenschaften 3 und 4). Eigenschaft 2 kommt ins Spiel, wenn ein Angreifer weshalb auch immer Zugriff auf die gehashten Passwörter in der Datenbank hat (zum Beispiel ist unser Angreifer der Datenbankadmin, oder die Datenbank wurde durch eine Sicherheitslücke öffentlich). Nur mit dem Hashwert kann sich niemand in euren Account einloggen, da er nicht weiß, welches Passwort er eingeben muss, um auf der Serverseite den Hashwert zu erzeugen. Eigenschaft 2 erschwert das Erraten des Passworts bei gegebenem Hashwert ungemein.

Und was macht Fonic jetzt falsch?

Abgesehen davon, dass nie jemand nach einem Passwort fragen müssen sollte um Support zu leisten, folgendes:

Laut eigener Aussage brauchte Fonic die ersten drei Buchstaben meines Passworts, um mich zu identifizieren. Daraus folgt entweder:

  • Fonic verschlüsselt Userpasswörter gar nicht: Um sicher sagen zu können, dass die ersten drei Stellen meines Passworts die ersten drei Stellen meines Passworts sind, muss Fonic die ersten drei Stellen meines Passworts wissen (d’uh). Wenn sie jetzt die Passwörter umverschlüsselt speichern, hat jeder Mensch, der Zugriff auf die Datenbank hat, Zugriff auf mein Passwort. Und das wäre ziemlich schlecht. Oder:
  • Fonic hasht die ersten drei Zeichen getrennt vom gesamten Passwort: Das wäre eine bessere Option, aber immer noch nicht ideal. Angenommen, Fonic erstellt 2 Hashwerte sobald ich mein Passwort ändere; einen über die ersten drei Zeichen, und einen über das gesamte Passwort. Dann würde Fonic die von mir übermittelten drei Zeichen hashen und mit dem Wert in ihrer Datenbank vergleichen. Stimmen beide überein, bin ich vermutlich der, für den ich mich ausgebe. Das Problem dabei ist, dass es so sehr leicht ist, an die ersten drei Stellen meines Passworts zu gelangen. Wenn man den Hashwert der Stellen hat, dauert ein Brute-Force-Angriff unter einer Sekunde (zumindest in meinen Tests). Angenommen, mein Passwort ist 6 Zeichen lang, von denen 3 Stellen bekannt sind, dann sind nur noch 3 weitere (statt 6) zu erraten. Zwei mal dreistellige Hashes zu brute-forcen ist um Größenordnungen schneller, als ein mal ein 6-stelliges Passwort zu erraten. Kurzes Rechenbeispiel: Als Passwörter seien nur Kombinationen aus 26 Kleinbuchstaben erlaubt; und unser Rechner kann 1000 Passwörter pro Sekunde generieren, dann dauert es 2 \cdot \frac{26^3}{1000\cdot \frac{1}{s}}  = 2 \cdot 17.576s = 35.152s um zwei jeweils 3-stellige Passwörter zu erraten. Für ein 6-stelliges Passwort kommen wir auf \frac{26^6}{1000\cdot \frac{1}{s}} = 308915.776s \approx 86h . 86 Stunden statt einer halben Minute; das ist ein erheblicher Unterschied.
    Oder:
  • Fonic verzichtet auf den Lawineneffekt: Extrem unwahrscheinlich. Wenn Fonic eine Hashfunktion einsetzte, die angewendet auf die ersten Stellen eines Passworts einen ähnlichen Hashwert wie für das gesamte Passwort berechnete, könnte die Korrektheit der übermittelten Stellen leicht überprüft werden.

Fazit

Egal, was Fonic macht; wenn sie ihre Benutzer mit Hilfe der ersten drei Zeichen ihres Kennworts identifizieren können, ist das Kennwortsystem seitens Fonic mit großer Wahrscheinlichkeit nicht sicher.
Was Fonic tun sollte: Passwörter nur gehasht in der Datenbank speichern und niemals Nutzer nach ihrem Kennwort oder Teilen davon fragen. Wenn Support über Twitter gegeben wird, muss lediglich darauf geachtet werden, dass die E-Mail-Adresse des Nutzers mit der bei Fonic hinterlegten übereinstimmt. Alternative: Beim Support kann sich Fonic das komplett gehashte Passwort per Mail schicken lassen. Ist aber überflüssig.

Ich hoffe, dass Fonic dazu öffentlich Stellung nimmt und sich umgehend um die Absicherung der Passwörter kümmert.

Ich schlief wenig bevor ich diesen Eintrag schrieb; die Wahrscheinlichkeit von Rechtschreib-, Denk- und Rechenfehlern ist deshalb relativ hoch. Darauf lasse ich mich gerne in den Kommentaren hinweisen.