Passwortklau am Beispiel LinkedIn

Momentan regen sich alle wieder auf, weil irgendwo Passwortlisten aufgetaucht sind. In diesem Fall stammen sie von LinkedIn, so die Meldungen. Aber auch eHarmony und Last.fm sind betroffen, wird gemeldet.

Passwortklau klingt im ersten Moment so, als wären die eigenen Zugangsdaten für die Diebe offen sichtbar. Sind sie aber nicht, denn nicht die Passwörter wurden geklaut, sondern deren Passwort-Hashes.

Das heißt, wenn es denn so ist, dass keine kompletten Zugangsdaten die einem User zugeordnet werden können, gestohlen wurden. Es sind Hashes die aus Passwörtern mit einer Einwegfunktion gebildet wurden. Man kann solche Hashes nur rückentschlüsseln, wenn man sehr leistungsfähige Rechner (meistens benützt man Grafikkarten) daransetzt und Unmengen an bekannten Passwörtern aus einer Liste (Rainbow-Table) damit vergleicht, ob sie den gleichen Hash ergeben, und wenn das nicht klappt, wird so lange eine Kombination aus allen möglichen Zeichen angesetzt, bis der gleiche Hashwert erzeugt werden kann. Wenn die Hashwerte übereinstimmen, hat man das Passwort.

Das klingt für uninformierte nach enorm viel Rechenaufwand, und das stimmt auch, aber inzwischen gibt es bezahlbare PCs, die eine Leistung bringen wie sie früher nur bei Supercomputern der Fall waren, und insbesondere sind hier die Grafikkarten hervorzuheben, die bei solchen Berechnungen erheblich schneller sind als der Prozessor des PCs. Das heißt auch, dass wenn die Liste einmal in den Händen der Diebe ist, wird ein solcher Rechner einem Hash nach den anderen ein Passwort zuordnen können.

Ohne komplette Zugangsdaten aber nützt das noch gar nicht viel, denn man müsste noch wissen, bei welchem User gebe ich das Passwort ein.

Da kommt dann vermutlich die nächste Stufe ins Spiel, die Portale werden noch einmal angegriffen, und zwar mit bekannten Nutzerdaten, denn die Diebe wissen, eines der Passwörter aus der Liste könnte passen. Statt mit massivem Brute Force Angriff reicht schon ein kleinerer Angriff, weil im Verhältnis die Menge der Passwörter deutlich kleiner ist als die Menge aller möglichen Kombinationen.

Nun könnten sich die betroffenen Portal entsprechend sichern, indem sie bei der Eingabe einen Filter auf menschliches Verhalten einbauen, denn Menschen geben nicht 1 Million Passwörter in der Sekunde im Anmeldeformular ein. Kleine Pausen nach jeder falschen Eingabe würde Angriffe in die Länge ziehen und ein Programm das stetige Fehleingaben überwacht, könnte solche Angriffe vielleicht finden bevor sie Erfolg haben.
So gesehen muss eine Hash-Liste von Passwörtern noch nicht der Supergau sein.

Was aber bezwecken die Diebe mit solchen Listen?

Man kann sehr leicht Portal- oder Forenbetreiber damit erpressen, nicht immer um Geld. Man kann die Listen weiter verkaufen oder schlicht damit glänzen, dass man es geschafft hat (wenn auch im stillen Kämmerlein). Es gibt aber sicher auch welche, die handfeste Interessen an den Daten der User haben, und das ist schon bedenklicher.

Da kann man die Aufregung schon verstehen. Irgendwie bin ich momentan froh, dass ich meinen LinkedIn Account vor einiger Zeit bereits gelöscht habe. Trotzdem ist das nicht endgültig beruhigend, weil ich weiß, dass in vielen Foren und Social-Media-Plattformen nie wirklich Userdaten gelöscht werden.

Das hat viele Gründe, unter anderem, weil Daten anlegen erheblich leichter ist als Daten löschen. Man darf das nicht mit dem eigenen PC verwechseln, wo per Mausklick einfach jede Menge Daten „gelöscht“ werden können, denn die Daten werden nicht wirklich gelöscht, sondern nur als gelöscht markiert. Und genauso wird es meistens in den Plattformen gemacht, weil Löschen zu viel Aufwand bedeutet.

Aber warum sind die Passwörter nicht mehr sicher?

Systeme die vor vielen Jahren entwickelt wurden, aber auch neuere Systeme die nicht nach neuesten Erkenntnissen entwickelt wurden, haben mehr oder weniger Altlasten zu tragen. Die md5-Enwegverschlüsselung galt früher als unknackbar, ganz einfach weil die Rechenleistung nicht ausreichte, um die Hashwerte mit so vielen Zufallskombinationen zu vergleichen.

Das hat sich drastisch geändert, inzwischen braucht es viel mehr Aufwand, Passwörter sicher zu machen und es gibt ganz gute Verfahren dafür, insbesondere welche die durch die schnellen Grafikkarten eben nicht so schnell ausgerechnet werden können, wie PBKDF2.

Und warum machen die Plattformbetreiber das nicht so?

Warum es die oben genannten Betreiber wohl nicht so machten, weiß ich natürlich nicht, aber warum es generell vermutlich viele solcher Leichen im Keller gibt, darüber kann ich was erzählen.

Software wird von Menschen gemacht und Menschen machen Fehler.
Software ist nur so gut, wie die Menschen die sie machen.
Software könnte oft besser sein, stünde nicht Zeitmangel und wirtschaftlicher Druck dahinter.
Sicherheitsstandards ändern sich stetig nach oben hin aber selten gibt es dafür ein extra Budget oder die Manpower, um diese auch einzubauen.
Refactoring ist auch ein Zauberwort für die Sicherheit, aber selten für die Betreiber.

Die Liste ist nicht vollständig, aber gerade der letzte Punkt ist sicher einer der Haupt-Gründe, warum viele Plattformen heute nicht mehr sicher sind, denn Portale wie oben genannte werden meistens von Grund auf neu Programmiert und nicht auf fertige CMS oder Frameworks aufgesetzt. Auch die Datenbank-Struktur wurde dereinst einmal festgelegt und irgendwann traut sich keiner mehr, daran noch groß etwas zu verändern.

Wer den Mut hat, eine sehr wichtige und riesige Tabelle die ununterbrochen massiv genutzt wird, zu ändern und dafür den Kopf hinzuhalten, der ist entweder völlig ahnungslos oder hat noch nie einen Gau an einem stark frequentierten Portal fabriziert und den Chef als auch die User gehört oder aber er kennt das alles und weiß wirklich was er tut. Aber warum ziele ich auf die Tabelle ab? Weil z.B. die MySQL Datenbank es erlaubt, Daten wie Passwörter an die Tabelle als Klartext zu senden und dieses dann von der Datenbank z.B. in ein MD5-Hash umgewandelt wird.

Das genügte früher als „Sicherheit“, denn so waren die Passwörter nicht im Klartext in der Tabelle gespeichert und MD5 galt bei vielen bis vor kurzem noch als nicht knackbar. Sogar heute laufen noch sehr viele Webseiten mit diesem System, ganz einfach weil die CMS-Entwickler bisher noch keine Verbesserung herausbrachten (nicht jeder Programmierer ist auch Sicherheits-Spezialist) oder schon lange kein Update mehr gemacht wurde.

Und selbst wenn es einen im Team gibt der sich mit Sicherheit auskennt, oder zumindest Ahnung hat, dann heißt das noch lange nicht, dass er beim Betreiber Gehör findet. Denn, Achtung Ironie, Sicherheit muss irgendwie so nebenbei gehen, darf nichts extra kosten, weil Programm-Entwickler sich ja alle an die Standards halten (wer oder was definiert hier den Stand der Technik und wo werden sie veröffentlicht und wie ist die Aktualisierung?) und diese kennen. Geht dann mal was schief wie in den aktuellen Fällen, ist der Entwickler schuld, aber nie derjenige, der für Sicherheit kein Budget hatte, also der Betreiber.

Und immer neu machen geht nicht, denn „Neu“ bedeutet oft auch, dass altbewährte Funktionen vergessen wurden und viele Fehler nochmal von vorn gemacht werden. Und ab einer Größe schon weit unterhalb der von LinkedIn ist „neu“ machen keine Option mehr, dann kann man nur noch den Code ständig überarbeiten und verbessern, aber man kann nicht das System immer wieder neu aufbauen.

Flukturation der besten Köpfe?

So müsste also konsequenterweise jeder Entwickler kündigen, wenn er sieht, dass etwas zu einem Problem werden könnte aber sein Chef keine Freigabe dafür gibt, sich um das anbahnende Problem kümmern zu können. Und tatsächlich wechseln viele Entwickler den Job, weil es ihnen dort nicht mehr gefällt, weil ihnen zu enge Vorgaben gemacht werden und weil Problemstellen nicht angegangen werden können mangels Zeit.

Oft wird nur nach vorne entwickelt, neue Features der Konkurrenz wegen die zur Featuritis führen können, aber selten zu einem stabilen System. Und wenn der ursprüngliche Entwickler (oder Chefentwickler) das damalige Sicherheitskonzept (falls es das je gab) noch durchschaute, so wird dieser sicher meistens neuen Aufgaben zugewandt haben oder den Job gewechselt und übrig bleibt ein oder mehrere Nachfolger, die eine Menge Code vor sich finden und erst erfassen müssen, welche Zusammenhänge alles hat und was die kleinste Änderung alles bewirken kann.

Den Nachfolgern fehlt dann oft der Überblick über tausend Dateien und hunderttausende Zeilen Code oder gar Millionen. So wird dann eher an Details etwas verändert (Großbuchstaben und Zahlen einbauen) statt grundlegend das Konzept überarbeitet. So kann es passieren, dass ein Nachfolger Passwortvorgaben mit Grossbuchstaben einbaut, jedoch nicht merkt, dass hintendran irgendeine vergessene Funktion alles in Kleinbuchstaben umwandelt, bevor es gespeichert oder verglichen wird.

Damals hatte das den Sinn, weil viele User Passwörter mal mit großem Anfangsbuchstaben schrieben und ein andermal nicht. Das ist die menschliche Ungenauigkeit und um hier verzweifelten (*Windows-) Usern vorzubeugen, wurde einfach alles in Kleinbuchstaben umgewandelt.

Inzwischen rächt sich solcher Komfort und der ursprüngliche Entwickler hätte vielleicht noch gewusst, dass er diesen Komfort eingebaut hatte.

*Windows wandelt intern alles in Kleinbuchstaben um, so dass eine Datei.TXT gleich datei.txt ist. Unix oder Linux machen das nicht, bei den Systemen ist datei.TXT nicht gleich datei.txt. Das nervt Windows-User hier und da aber auch uns Webentwickler, weil manche Windows-Programme beim Speichern nicht alles in Kleinbuchstaben umwandeln, sondern aus einer geöffneten datei.txt auch gerne mal ein datei.TXT machen.

Hersteller (ich nenne sie lieber Betreiber, denn herstellen im Sinne von etwas herstellen – anfertigen, tun wir, die Programmierer), wissen oft nicht um ihren Code, weil sie keinen Einblick mehr in die Detalis haben und im Gegenteil sogar hören, „wir haben jetzt Unterscheidung in Groß- und Kleinbuchstaben eingebaut“ und sich sicher wiegen. Auf die Idee, dass man jemanden der sich mit dem Thema Sicherheit auskennt, regelrecht abstellen muss um den ganzen Code auf Sicherheit zu überprüfen und ein Konzept aufzustellen, kommen wirklich nicht alle (eher keiner, außer aufmerksamen Chefentwicklern, Teamleadern).

Sicherheit durch bessere Verschlüsselung?

Sicherheit im Programm ist nicht nur jeweils die schlaueste Verschlüsselungstechnik zu nehmen (wie hier vorgeschlagen), sondern ein größerer Zusammenhang und daher kein eher zufälliges Nebenprodukt der Programmierung, sondern ein eigener Posten in größeren Projekten. Ich darf nämlich durchaus zu dem Security-Artikel fragen, wie kamen denn die Diebe überhaupt an die Passwortliste?

Etwa durch SQL-Injection? Dann war hier schon die Lücke und nicht erst im Hash. Passwörter komplex zu verschlüsseln ist eine nette Idee, aber erstens kostet es Rechenzeit (doch, und gerade bei stark frequentierten Portalen oder schwachen Servern macht sich das unangenehm bemerkbar) und zweitens habe ich auch schon Hacker-Daten gefunden, die Passwörter im Klartext vor der Verschlüsselung direkt bei der User-Eingabe abzapften (mit allen weiteren Daten die User bezogen eingegeben wurden). Was nützt es da, mit PBKDF2 sicher verschlüsselte Passwörter zu haben, wenn das System an anderen Stellen offen ist wie ein grobmaschiges Fischernetz?

Wäre das System also dicht gewesen, wäre niemand an die Hashwerte der Passwörter gekommen.

Natürlich machen besser verschlüsselte Passwörter einen gewichtigen Sinn, keine Frage,  aber Sicherheit ist immer relativ zu sehen und nur im Konzept wirkt es am besten.

Und ich denke mir, dass die betroffenen Betreiber keine schnelle Lösung finden werden, denn ohne Frage gibt es Lücken (die durchaus auch mal im Personal sein könnten) und ein Sicherheitskonzept stellt sich nicht schnell mal so auf und schon gar nicht kann es hopplahopp umgesetzt werden.

Ich sehe immer mehr den Sicherheitsbeauftragen als Vollzeitjob im Entwicklungsteam aber auch als freier Consultant für kleinere Betreiber im kommen. Zwar wurde im Heise-Security-Artikel ein Nachweis über Sicherheitsstandards gefordert, aber das ist ein zweischneidiges Schwert, denn Sicherheit kostet Geld, defintiv, und nicht nur das, es muss auch machbar sein. Kleine Betreiber dürften es nicht schaffen, sich an diesen Standard zu halten, denn dann wäre SSL obligatorisch und keine Option und eine ständige Pflege des Sicherheitskonzeptes wäre nötig (Entwicklerkosten) und ihnen liegt oft nicht die gesamte Kontrolle des Gesamtsystems in der Hand (Shared Hosting). Würde man diese Standards gesetzlich verbindlich fordern, wäre das Internet leer und einsam.

Von so großen Playern wie LinkedIn könnte man aber schon erwarten, dass sie Vollzeit-Sicherheitsbeauftragte haben und dass es interne Programmier-Standards gibt, die auch eingehalten und vom Chefentwickler überprüft werden.

Dass es in der Realität anders aussieht, weiß ich zur genüge. Ich hatte selbst schon als Teamchef Programmier-Standards vorgegeben und kaum drehe ich den Rücken hin, wird wieder Quick and Dirty programmiert. Flöhe hüten ist leichter als inkonsequente Programmierer unter Termindruck. Es liegt aber auch daran, dass gerne Studenten, Schüler und jeden der sich billig anbietet, genommen werden, damit es eben möglichst wenig kostet.
Quick’n’Dirty geht schnell und billig und bei dem Entwicklungstempo wie sich manche Portale entwickeln, kann man nur davon ausgehen, dass so programmiert wird, denn sonst bräuchten sie ein Heer an guten Entwicklern und die sind teuer.

So fängt in meinen Augen Sicherheit nicht erst bei der Verschlüsselung an, sondern bereits schon im Personalbüro.

Über Frank König

Der Chef hier...
Dieser Eintrag wurde veröffentlicht in Allgemein, Webdesign und getaggt . Lesezeichen für den Permalink.
Jeder Kommentar wird überprüft.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.