Ganz am Anfang eines Informatikstudiums, einer Ausbildung zum Fachinformatiker, eines Kurses für Systemadministratoren oder auch nur wohl so ziemlich jeden beliebigen Tutorials für Web-Entwicklung wird einem ein unumstößliches Mantra eingebläut: „Ich darf keine Passwörter im Klartext speichern“.
Das hat seine Berechtigung, und die Erklärung dafür sollte jedem sofort einleuchten: Wenn mein Passwort lesbar in eine Datenbank gespeichert wird, kann es eben auch jeder lesen (und damit auch überall sonst verwenden, wo ich dasselbe Passwort nutze), der Zugang zu dieser Datenbank hat. Dafür braucht es noch nicht einmal diese bösen Hacker* oder die liebe NSA, es reicht praktisch jeder Mitarbeiter des Dienstes, der diese Datenbank betreibt, jeder hinzugezogene externe Servicetechniker oder im blödesten Falle ein schlimmer Bug aus, der die Datenbankinhalte ganz oder auszugsweise jedem offenlegt.
Trotzdem gibt es Webdienste, die diese Grundregel der Internetsicherheit nicht beachten und die Passwörter ihrer Kunden gewissermaßen achtlos in die Ecke stellen.
Abhilfe: Hashing
Eigentlich braucht es keine Hexerei, um das Klartextspeichern von Passwörtern zu vermeiden und trotzdem Logins zu ermöglichen. Sogenannte kryptografische Hashfunktionen erlauben es, auf eindeutige (das heißt: beliebig oft wiederholbare) Weise aus Zeichenketten völlig andere Zeichenketten zu berechnen, ohne dass der umgekehrte Weg mit vertretbarem Aufwand möglich wäre. Mit dem beliebten MD5-Verfahren etwa wird aus „MeinGeheimesPasswort“ zuverlässig und ohne großen Berechnungsaufwand „e9eaf651acd235efc53471aed55ee363“. Ich registriere mich also mit meinem Passwort, auf dem Server wird das aber nie gespeichert, sondern jener Hash. Wenn ich mich nun einloggen will, natürlich ebenfalls mit meinem Passwort, wird das erneut gehasht, und es kommt derselbe Hash heraus, der auch auf der Datenbank gespeichert wurde. Damit ist dem Server klar, dass ich dasselbe Passwort wie bei der Registrierung verwendet habe – ohne dass er es je gespeichert hat. Jemand, der nun auf der Datenbank sieht, dass mein Passwort-Hash „e9eaf651acd235efc53471aed55ee363“ ist, kann damit ohne Weiteres nichts anfangen, denn daraus das Passwort zurückzuberechnen ist praktisch nicht möglich, und direkt mit dem Hash kann er sich bei Amazon, GMail, PayPal und meiner Bank nicht einloggen, selbst wenn ich dort dasselbe oder ein nach einem ähnlichen System aufgebautes Passwort verwende.
Das Ende des Wettrüstens der Serverbetreiber und der Hacker (was hier stellvertretend für alle steht, die an mein Passwort kommen wollen), ist damit freilich noch nicht erreicht. Denn die prinzipielle Stärke dieses Verfahrens, die Eindeutigkeit der Hashfunktion, ist auch ihre größte Schwäche. Der Hacker kann nun schließlich hergehen und sich eine Tabelle mit Hashes für alle möglichen Passwörter machen – der Hash für Passwort „a“ ist immer „0cc175b9c0f1b6a831c399e269772661“, der für Passwort „b“ immer „92eb5ffee6ae2fec3ad71c777531578f“, und so weiter, bis irgendwann in der Tabelle auch „MeinGeheimesPasswort“ auftaucht, zuverlässig mit dem Hash „e9eaf651acd235efc53471aed55ee363“. Nun weiß der Hacker eben doch, dass zu dem Hash „e9…“ „MeinGeheimesPasswort“ gehört. Eine solche „Rainbow-Table“ (Informatiker-Poesie: Sie enthält, sinnbildlich gesprochen, jede Farbe des Regenbogens) ist, wenn sie halbwegs umfassend sein soll, recht aufwändig zu erstellen, lässt sich für verbreitete Hashfunktionen (und nur diese erprobten Funktionen sollte man nutzen, denn die Chance ist groß, dass eine selber ausgedachte Hashfunktion fatale Lücken in ihrer Einweg-Eigenschaft oder anderen wichtigen Parametern aufweist) aber vorgefertigt kaufen. Dagegen hilft es, den Hash zu „salzen“, dem Passwort also vor dem Hashen eine möglichst zufällige Zeichenkette anzuhängen – die Chance, dass auch der passende Hash für „S3q7f7R3nIlJUgeB§j19YWF#l6!&Yo17$y!“6QjMeinGeheimesPasswort“ in der Rainbow Table enthalten ist, dürfte dann doch ziemlich gering sein. Wenn dann das Ganze auch nicht nur einmal, sondern tausend Mal gehasht wird, dann ist dem mit einer Rainbow Table nicht mehr beizukommen.
Langer Rede kurzer Sinn: Jeder, der ein Login-System für’s Web (oder sonst irgendwas mit Passwörtern) programmiert, und von seinem Handwerk etwas versteht, wird sich nach Möglichkeit hüten, Passwörter nur per ungesalzenem Hash zu schützen, auch wenn das natürlich schon tausendmal sicherer ist als gar nix. Und dennoch gibt es immer wieder Web-Dienste, die auf Hashing komplett verzichten und die Passwörter ihrer Nutzer jedem im Klartext präsentieren, der nicht schnell genug wegrennen kann. Die Nutzer selbst haben bei Online-Diensten** leider kaum Möglichkeiten, herauszufinden, ob ihr Passwort bei diesem Anbieter denn nun sicher verwahrt ist oder offen herumliegt. Anderthalb Gelegenheiten gibt es typischerweise aber doch, um einen Anbieter bei einer solchen Schlamperei zu ertappen. Ein erstes Indiz liefert die Mail, die die Registrierung bestätigt. Steht in der das Passwort, heißt das zwar nicht unbedingt, dass es auch auf dem Server ungehasht gespeichert ist, offenbart aber zumindest ein zweifelhaftes Sicherheitsverständnis – das Passwort, das ich ja weiß, weil ich es gerade selbst eingegeben habe, wird ohne Not unverschlüsselt durch die Gegend geschickt (E-Mails können auf ihrem Weg zum Empfänger im Prinzip auch Hinz und Kunz mitlesen, ähnlich einer Postkarte) und dann in meinem Postfach womöglich auf ewig gespeichert, so dass wiederum jeder, der darauf Zugriff erlangt ohne weiteres Zutun mein Passwort weiß. Wirklich verräterisch ist aber die Passwort-Erinnerungs-Mail nach dem Drücken auf den berühmten „Passwort vergessen“-Link. Kommt daraufhin ein neu generiertes Passwort per Mail, wurde das ursprüngliche Passwort wahrscheinlich gehasht gespeichert. Erreicht mich eine Mail, in der mich das von mir einst selbst gesetzte Passwort fröhlich anlächelt, dann ist der Anbieter ein Stümper und hat mein Passwort so gespeichert, dass es jeder lesen konnte.***
Trotzdem Klartext
So etwas ist mir im Januar 2012 beim Schweizer Videostreamingdienst Viewster passiert. Auf meine Mail, in der ich auf diese eklatante, aber im Prinzip auch im Nachhinein leicht zu schließende**** Sicherheitslücke hinwies, kam nie eine Antwort. Und wie ich mich bei meiner testweisen erneuten Registrierung zweieinhalb Jahre später sehe, auch keine interne Reaktion – Viewster speichert die Passwörter seiner Nutzer weiterhin ungehasht.
Wer bei Viewster dasselbe Passwort verwendet wie anderswo, sollte seine Passwörter nicht nur bei Viewster, sondern eben auch anderswo ändern und dabei möglichst von dieser Bad Practice ganz abkommen und ein Passwort-System verwenden. Aber auch mit einem solchen kriegt man ein gewisses Problem, denn der Angreifer kann nun von einem konkreten Beispiel aus versuchen, dieses System zu knacken und damit auch an die Passwörter für andere Dienste zu kommen. Und selbst wer die Gefahr dafür gering einschätzt oder ein Viewster-Passwort einsetzt, das tatsächlich unabhängig von allen anderen ist – würde man einem Anbieter, der erwiesenermaßen selbst bei den elementarsten Sicherheitsmechanismen versagt, etwa Kreditkarten- oder andere Zahlungsdaten anvertrauen wollen? Ich nicht.
Glücklicherweise ist es bei Viewster im Allgemeinen wohl nicht nur nicht nötig, etwas zu zahlen, sondern auch auf die Registrierung kann zur Nutzung verzichtet werden.
Per Google fanden sich erschreckend viele Meldungen zu ähnlichen Umständen bei anderen Anbietern, aber trotz Webseiten wie passwordfail.com und plaintextoffenders.com keine Zusammenstellung von im deutschsprachigen Raum relevanten Diensten, die derart unsicher sind. Nicht alle Reports konnte ich überprüfen, da man sich natürlich nicht überall „einfach so“ anmelden kann, weshalb ich die Meldungen zu Fonic, der LBB-Bank Berlin und den Webhostern Evanzo und all-inkl hier nur unverifiziert (aber, soweit bekannt, immerhin undementiert, wobei es bei Fonic zumindest heißt, dass nur die ersten drei Zeichen im Klartext verfügbar sind, und dass auch andere Anbieter das tun, was etwa bei Simyo tatsächlich auch der Fall ist) weiterreichen kann. Weitere etwa 20 halbwegs aktuelle Meldungen in diversen Foren, Blogs und Mailinglisten bin ich systematisch durchgegangen, dabei aber zum Glück zu dem Ergebnis gekommen, dass die meisten Sünder von einst inzwischen nachgebessert haben und ich mein angeblich vergessenes Passwort nicht mehr im Originalzustand zugeschickt bekam.
Übrig blieben – zugegeben erwartungsgemäß – nicht unbedingt die Big Player der D-A-CH-Webszene (wobei etwa PC Games und das Online-Spiel OGame natürlich auf das initiale Versenden des Passworts verzichten könnten, aber das alleine ist eben noch keine Katastrophe). Besonders peinlich wohl die alteingesessene Webmaster-Website php-resource.de, in deren Forum 2013 reaktionslos auf die Klartextpasswörter hingewiesen wurde. Daneben fand ich zwei regionale Communitys – bei NB-Town (Neubrandenburg) muss die Schwachstelle den Betreibern schon seit 2012 bekannt sein, ohne dass sich was getan hätte (hier verwendet man aber nach eigener Aussage zumindest eine Verschlüsselung – überprüfen lässt sich das nicht), und im Forum von schlach.com (Eifel) wurde das Problem gar mindestens schon 2011 gemeldet und ist immer noch nicht behoben (und daneben fehlt der Seite auch ein Logout-Link).
Schlussfolgerung
Auch wenn in meinem Test also nur wenige, eher unbedeutende Anbieter mutmaßlich Klartextpasswörter speicherten, so sollte man dennoch einige Dinge beherzigen. Zunächst mal natürlich, dass niemals dasselbe Passwort für mehrere Dienste genutzt werden sollte. Wer Passwörter pro Dienst nach einem bestimmten System erzeugt, der sollte darauf achten, dass dieses nicht zu durchsichtig ist – wenn der Hacker sieht, dass mein Passwort bei Facebook „MeinGeheimesFacebookPasswort“ lautet, dann wird er an meinem E-Mail-Passwort oder dem für den Rechner an der Arbeit womöglich nur bedingt lange zu knabbern haben. Wem ein bestimmter Dienst bei der Anmeldung sein Passwort im Klartext zusendet, der sollte hellhörig werden, und wer einen vielleicht noch nicht gänzlich etablierten Dienst für wichtigere Dinge nutzen will, der sollte vielleicht mit einem Müll-Passwort beginnen und erstmal die Passwort-Zurücksetzen-Funktion ausprobieren. Liefert die das eigene Passwort zurück, ist von der Nutzung abzuraten.
Und noch ein Wermutstropfen zum Schluss: Letztlich schützt auch vermeintliches Expertentum nicht vor solchen Fehlern. Auf den Servern des IEEE, des wohl wichtigsten IT-Verbands der Welt, gab’s eine Zeit lang die Klartextpasswörter der Nutzer der Website sogar ganz bequem und schön gesammelt zum Download.
- * …die unlängst etwa beim Dating-Netzwerk Cupid an 40 Millionen Klartextpasswörter kamen ↑
- ** Anders ist das bei lokalen Anwendungen auf dem PC oder Apps auf dem Smartphone. Dort sind Auswirkungen allerdings nicht so drastisch, weil derjenige, der an das auf meiner Festplatte gespeicherte Passwort kommt, damit eben nicht automatisch auch die Passwörter aller anderen Nutzer der App hat. Trotzdem ist es nicht gerade doll, dass diese Praxis daher noch wesentlich verbreiteter als im Web ist. ↑
- *** Oder er hat das Passwort verschlüsselt, statt es zu hashen, was – wenn der Schlüssel sicher aufbewahrt und die Verschlüsselungsmethode an sich nicht geknackt ist – zwar zumindest dem Feld-Wald-und-Wiesen-Hacker mein Passwort verbirgt, den Server-Admin aber nicht daran hindert, sich mal eben an den Passwörtern der User zu bedienen. Und wenn die Daten nur interessant genug sind – das dürfte etwa für die letztes Jahr erbeuteten 150 Millionen verschlüsselten, nicht verhashten Adobe-Passwörter anzunehmen sein –, dürfte es sich auch für Hacker lohnen, zu versuchen, die Verschlüsselung zu knacken. ↑
- **** Einfach ein Login mit Hashing implementieren, alle gespeicherten Klartextpasswörter hashen und die Originale löschen – fertig. ↑