Sammeln Sie Meilen? Sind Sie Mitglied in unserem Bonusprogramm? Wie lautet Ihre Vielfliegernummer? Geht es nur mir so oder nervt es langsam wirklich, dass man bei jedem Einkauf danach gefragt wird.
Wenn ich bei allen Programmen mitmachen wollte, hätte ich wahrscheinlich 20 oder mehr Plastikkarten in meinem Portemonnaie. Und natürlich braucht man, um die gesammelten Punkte, Meilen oder was auch immer für eine „Währung“ sie sich ausgedacht haben, zu nutzen, eine PIN. Oder ein Passwort. Ich habe keine Ahnung, wie ich mir die alle merken soll – geschweige denn, dass ich für jede Karte und jeden Dienst ein eigenes wähle. Oder wie jemand anderes dazu in der Lage sein sollte.
Ich würde sagen, das macht die passwortbasierte Authentifizierung zur am häufigsten implementierten Funktion im Web. Man würde annehmen, dass es kaum mehr als die sprichwörtliche Fingerübung ist, da Entwickler auf der ganzen Welt es immer wieder implementieren. Angesichts der Menge an (Open Source-)Frameworks für PHP sollte es viele fertige – und sichere – Lösungen für alle Arten der Verifizierung geben. Dennoch sehen wir wöchentlich kompromittierte Dienste und geleakte Benutzerdaten.
LinkedIn hat neulich ca. 6,5 Millionen Passwort-Hashes verloren, last.fm gelang dasselbe mit 2,5 Millionen Hashes – um nur die prominenteren Websites zu nennen. So peinlich es auch sein mag, zugeben zu müssen, dass ein Angreifer es geschafft hat, einzubrechen und sogar die Benutzerdaten mitnehmen konnte, ist es nur eine Frage der Zeit. Es gibt keine 100-prozentige Sicherheit und sobald ein Server in Betrieb ist, wird er zwangsläufig angegriffen werden.
Da es sehr wahrscheinlich ist, dass ein erfahrener Angreifer irgendwann Zugriff auf die Benutzerdaten erhält, ist es umso wichtiger, darüber nachzudenken, wie man diese Informationen sicher speichern kann. Und hier ist es, wo die Dinge wirklich peinlich werden: Viele Websites speichern ihre Passwörter immer noch im Klartext in ihrer Datenbank! Ein Sicherheitsalbtraum, der damit erklärt wird, dass sich die Administratoren oder das Supporter-Team als Benutzer ausgeben können müssen. Oder um dem Benutzer das Passwort per Mail zukommen lassen zu können, falls er es erneut anfordert. Beide angegebenen Usecases sind unecht. Schauen wir uns den ersten an, die Notwendigkeit, sich als Benutzer auszugeben. Es mag zwar von vertretbarem Wert sein, dies tun zu können, aber wenn ich die Kontrolle über das gesamte System habe, warum sollte ich dazu eine tatsächliche Anmeldung mit dem Passwort des Benutzers verwenden müssen? Das einfache Einfügen einer passenden Sitzung sollte hier ausreichen.
Bleibt noch das Versenden des aktuellen Passworts: Normalerweise wird es in einer unverschlüsselten E-Mail verschickt, die jeder lesen kann. Das ist ungefähr so sicher wie das Versenden einer Postkarte. Oder Sie drucken den „sicheren Code“ auf die Rückseite Ihrer Kreditkarte, zusammen mit Ihrem Namen und allem anderen, was Sie brauchen, um die Karte zu benutzen – und geben sie dennoch jemandem, den Sie nicht kennen, zur Zahlung. Eigentlich erstaunlich, dass die Menge des Missbrauchs noch nicht über die regelmäßige Nutzung hinausgewachsen ist. Aber zurück zum Thema. Der einzige vernünftige Weg, ein Verfahren zur Wiederherstellung eines verlorenen Passworts zu implementieren, besteht darin, weder das ursprüngliche noch ein neu generiertes Passwort zu verschicken, sondern lediglich einen Token, damit der Benutzer selbst ein neues Passwort aussuchen kann, wobei er diesen Token als Verifizierung verwendet, bevor er das neue Passwort akzeptiert.
Da wir also keinen Bedarf haben, auf eine Klartextversion des Passworts zuzugreifen, können wir darauf verzichten, es zu behalten und stattdessen einen Hash speichern. Die Verwendung eines Hashes ist eine gute Option, da wir das ursprüngliche Kennwort weder kennen noch wiederherstellen müssen. Ein Hash, im Grunde eine ausgefallene Prüfsumme des gegebenen Passworts, ist ein ziemlich wichtiger Bestandteil der Verschlüsselung, hat aber nichts damit zu tun. Prüfsummen und damit Hashes wurden ursprünglich nur verwendet, um sicherzustellen, dass sich Daten nach der Übertragung nicht verändert haben, sei es durch absichtliche Änderungen oder durch Transportfehler. Angesichts dieses Anwendungsfalls sind fast alle Hash-Algorithmen auf Geschwindigkeit optimiert. Und so ist die Berechnung von Hashes sehr schnell – eine durchschnittliche Laptop-CPU kann etwa 500.000 Hashes pro Sekunde für eine Nutzlast von sagen wir 8 Zeichen langen Strings berechnen.
Was aus Sicht der Performance gut ist, entpuppt sich in diesem Zusammenhang als Problem: Allein die Berechnung der Hashes für alle möglichen Kombinationen von Zeichen und Zahlen von Passwörtern üblicher Länge dauert nicht sehr lange. Danach ist das „Umkehren“ des Hashes zum Wert nur noch ein Nachschlagen. Die sogenannten Rainbow Tables sind überall im Netz zu finden, was einen einfachen Hash in Bezug auf die Sicherheit unbrauchbar macht.
Die Lösung hierfür ist allerdings recht einfach: Fügen Sie Salt hinzu. Durch Hinzufügen eines eindeutigen Wertes pro Benutzer sowie eines seitenweiten Tokens müsste ein Angreifer die zuvor erwähnte Rainbow-Tabelle für jeden Hash/Passwort neu berechnen. Und er muss Zugriff auf den Seiten-Token haben. Das alles macht es natürlich nicht kugelsicher, aber es gibt Ihnen und Ihren Benutzern Zeit, die Passwörter zu ändern. Wenn der Angreifer es also endlich geschafft hat, alle Hashes neu zu berechnen, sind sie veraltet.
Aber warum brauche ich überhaupt so viele Konten, Logins und Passwörter? Wenn man sieht, dass die Leute keine individuellen Passwörter verwenden, dass Websites die Hashes ausspähen und natürlich, dass die Benutzer ihre Anmeldedaten vergessen, stellt sich mir die Frage, warum wir uns immer noch auf standortspezifische Logins verlassen. Es gibt Konzepte wie OpenID oder BrowserId , die den Benutzern das Erstellen von Logins und das Ausdenken von sicheren und dennoch einprägsamen Passwörtern abnehmen. Und beendet die Notwendigkeit für Seiten wie LinkedIn oder last.fm, ein Passwort zu speichern und die Authentifizierung zu handhaben.
Fast wie eine generische Mitgliedschafts-Bonuskarte, die ich für alle Programme verwenden kann, denen ich beitreten möchte, wobei ich bewusst auswählen kann, welches zu einem bestimmten Zeitpunkt aktiv sein soll. Das Leben könnte so einfach sein.