Skip to content

Passwortlecks ohne Ende?

Heute gibt es Kommentare zu den diversen "Passwortlecks". Falls Sie einen Kommentar zu Flame und dem Windows-Update-Debakel erwartet haben: Die gibt es am Donnerstag zusammen mit Informationen zu den zugrunde liegenden Problemen und Flames Angriff. Jetzt interessieren mich erst mal die ausgespähten Passwörter von LinkedIn, eHarmony, Last.fm und Co.

Passwort-Hashes auf Abwegen

Zur Zeit wurden auf mehreren Websites Passwort-Hashes "geklaut". "Geklaut" ist ein in dem Zusammenhang gern genutzter, aus technischer Sicht aber völlig falscher Begriff, da die Daten ja kopiert wurden und noch da sind. Und anders als gestohlene Dinge können die Daten auch nicht "zurück geholt" werden - man weiß nie, wie viele weitere Kopien es gibt. Und die jetzt aufgetauchten Passwort-Hashes sind ja nur ein Teil der kopierten Daten, zu denen mit ziemlicher Sicherheit noch die Benutzernamen und evtl. weitere Daten gehören.

Aber werfen wir erst mal einen Blick auf die Opfer:

LinkedIn

Laut einem Mashable-Bericht wurden 6,46 Millionen mit SHA-1 gehashte, aber nicht gesalzene (dazu unten mehr) LinkedIn-Passwörter veröffentlicht. Von LinkedIn bestätigt wurde der Diebstahl einer ungenannten Anzahl an Passwörtern, als zusätzliche Sicherheitsmaßnahmen werden die Passwörter nun gehasht und gesalzen (hoffentlich in der umgekehrten Reihenfolge, sonst geht das in die Hose). 60% der zu den Hashes gehörenden Passwörter sind laut Sophos bereits berechnet worden, darunter laut Heise auch eigentlich als ziemlich sicher geltende wie "parikh093760239", "a06v1203n08" und "376417miata?" sowie das mit Sicherheit gut gewählte Passwort von Robert David Graham von Errata Security.

eHarmony

1,5 Millionen gehashter eHarmony-Passwörter wurden auf einer Website veröffentlicht, alle Passwörter sollen als Grossbuchstaben (uppercase) gehasht worden sein. Der Großteil der Hashwerte wurde in kurzer Zeit geknackt. Laut eHarmony ist nur "a small fraction of our user base" betroffen, die entsprechenden Passwörter wurden zurückgesetzt und die Benutzer informiert. eHarmony nutzt "robust security measures, including password hashing and data encryption", von Salz ist nicht die Rede. Aber die betrachten ja auch Loadbalancer als Teil ihrer Schutzmaßnahmen. Naja, in gewisser Hinsicht stimmt das ja auch, die verteilen DDoS-Angriffe gleichmäßig auf alle Server dahinter.

Last.fm

Auch Passwort-Hashes von Last.fm wurden veröffentlicht. Last.fm gibt selbst nur die Kompromittierung "einiger Last.fm-Nutzer" zu, für die neuen Passwörter werden bessere Sicherheitsmaßnahmen verwendet. Die Hashwerte sollen schon seit 2011 im Umlauf sein. Laut Heise handelt es sich aktuell um 2,5 Millionen MD5-Hashes, wobei es sich lediglich um die bisher nicht geknackten Einträge einer Liste mit 17 Millionen Hashwerten handeln soll. 15,4 Millionen / 95% davon sollen bereits geknackt worden sein. Ursache des Problems: Der Entwickler war jung und hatte von Sicherheit keine Ahnung. Außerdem senden die Geräte, die das mobile API nutzen, ungesalzene MD5-Hashes. Was nicht erklärt. warum man sie nicht auf dem Server besser gesichert hat.

"Ferner liefen..."

Laut Rhein-Zeitung wurden die Daten von 24.000 Nutzern der Website lustiges-taschenbuch.de kopiert, die Passwörter waren laut Betreiber der Website "verschlüsselt hinterlegt". Und laut Sophos wurde das Online-Strategiespiel "League of Legends" Opfer eines "data breach". Wie viele Daten kopiert wurden, ist nicht bekannt. Der Betreiber, Riot Games, berichtet über einen erfolgreichen Angriff auf die Website (die dabei ausgenutzte Schwachstelle wurde inzwischen behoben), bei dem "email address, encrypted account password, summoner name, date of birth" sowie in einigen Fällen Vor- und Nachname sowie die nicht mehr genutzten, verschlüsselten Sicherheitsfragen und -antworten ausgespäht wurden.

Woher kommen die Passwörter?

So ein "Passwortleck" führt natürlich zu einigen Fragen, z.B. danach, woher die Passwörter kommen. Das wüsste ich auch gerne, aber weder die Hacker noch die Opfer werden es uns verraten. Generell muss sich da in jedem Fall jemand Zugriff zu einem Server verschafft und die dort gespeicherten Hashes kopiert haben. Ob das über eine Schwachstelle wie im Fall von "League of Legends" passierte, ob evtl. Zugangsdaten von Administratoren etc. ausgespäht wurden, die Daten ungesichert auf dem Server lagen oder was auch immer passierte, ist nicht bekannt.

Wie gut geschützt sind die Passwörter?

Wie oben schon zu lesen war, sind sie im Grunde gar nicht geschützt, sie wurden nur als einfaches Hashwerte gespeichert. Im Fall von eHarmony wurden die Passwörter vor dem Hashen auch noch in Grossbuchstaben umgewandelt, als wollte man es den Angreifern besonders leicht machen. Normale kryptographische Hashwerte lassen sich mit Hilfe sog. Rainbow Tables recht schnell umkehren. Für viele Hashfunktionen und Passwortarten gibt es bereits fertig berechnete Rainbow Tables, z.B. hier, außerdem können die Tabellen natürlich "on the fly" gebildet werden.

Um so einen Angriff zu verhindern, werden die Passwörter normalerweise vor dem Hashen gesalzen: Ein (idealerweise für jedes Passwort neu gebildeter) Zufallswert, das sog. Salt, wird an das Passwort angehängt, der Hashwert berechnet und zusammen mit dem Salt gespeichert. Soll später das Passwort geprüft werden, wird analog vorgegangen: Der Salt-Wert wird an das Passwort angehängt, der Hashwert berechnet und mit dem gespeicherten Hashwert verglichen.

Ein Angreifer, der einen so gesalzenen Hashwert mit Hilfe einer Rainbow Table brechen will, muss für jeden Salt-Wert eine neue Tabelle berechnen, was das Ganze aber heutzutage auch nicht mehr unbedingt verlangsamt, die schnellen CPUs und vor allem GPUs machen es möglich, außerdem gibt es ja noch "die Cloud". Denn die allgemein einsetzbaren Hashfunktionen wurden in Hinsicht auf ihre schnelle Berechenbarkeit entwickelt, was natürlich auch einem Angreifer zu Gute kommt.

Wie z.B. die LinkedIn-Hashes geknackt werden, hat Robert David Graham beschrieben.

Was sollten Webentwickler und -admins tun?

Erst mal sollten die Anwendungen und Server natürlich sicher sein, so dass Daten gar nicht erst ausgespäht werden können. Im Falle eines Falles kommt es aber auf die "Defense in depth" an: Wenn Passwörter nur gehasht werden, können sie sehr schnell geknackt werden, wie man jetzt ja sieht. Die Passwörter dürfen also nur gesalzen gespeichert werden, und idealerweise sollte der Salt-Wert für jedes Passwort neu gebildet werden, so dass sich die für die Brechung eines Passwort erzeugte Rainbow Table nicht für weitere Passwörter verwenden lässt. Aber selbst dann lassen sich auch komplizierte Passwörter oft noch effektiv berechnen.

Jarno Niemela von F-Secure empfiehlt daher zu Recht den Einsatz spezieller Passwort Hashing Schemes wie PBKDF2, Bcrypt PBMAC oder scrypt. Bei diesen Verfahren wird besonderen Wert darauf gelegt, das Brechen von damit geschützten Passwörtern so sehr zu verlangsamen, dass es für einen Angreifer uninteressant wird.

Übrigens rät Poul-Henning Kamp, der Entwickler von md5crypt, vom Einsatz seines eigenen Programms zur Passwortverschlüsselung inzwischen ab. Die mit dem 1995 entwickelten Programm verschlüsselten Passwörter sind heutzutage nicht mehr sicher. Da stimme ich ihm zu, danach gibt er aber einen gefährlichen Rat:

"All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm (consisting of course of standard one-way hash functions like SHA2 etc) for their site, in order to make development of highly optimized password brute-force technologies a “per-site” exercise for attackers."

Bitte ignorieren Sie diese Aufforderung, sofern Sie nicht zufällig zur relativ kleinen Gruppe fähiger Kryptographen unter den Entwicklern gehören. Die Entwicklung sicherer kryptographischer Verfahren ist sehr schwierig, nicht umsonst wurden schon viele angeblich sichere Verfahren gebrochen. Die Gefahr, auch bei der Verwendung sicherer Standardfunktionen eine unsichere Kombination zusammen zu stellen oder anderweitig Fehler zu machen, ist einfach zu gross. Und es wäre doch ziemlich peinlich, wenn Ihr tolles individuelles Verfahren sich am Ende als so unsicher herausstellt, dass ein Angreifer damit weniger Mühe hat als mit ungesalzenen SHA-1-Hashes, oder?

Was sollten Benutzer tun?

Erst mal gilt: Fühlen Sie sich nicht in Sicherheit. Zwar wurden nur die Passworthashes und nicht die zugehören Benutzernamen veröffentlicht, aber die "Passwortdiebe" dürften auch die Benutzernamen kennen. Denn ohne ist das Brechen der Passworthashes zwecklos. Sie wurden nur nicht veröffentlicht. Warum auch, wenn man damit selbst Unheil anrichten will?

Sofern Sie einen der betroffenen Dienste nutzen, sollten Sie ihr Passwort ändern (sofern sie das noch nicht getan haben). Dabei müssen Sie darauf achten, keinen Phishern in die Hände zu fallen, denn wie das ISC berichtet, nutzen die die aktuellen Vorgänge bereits aus, um Benutzer nicht betroffener Websites auf Phishing-Seiten zu locken.

Wenn Sie also jemand z.B. per Mail oder Social Networks auffordert, ein Passwort zu ändern, folgen Sie keinen dabei angegebenen Links, sondern rufen Sie die betreffende Seite direkt auf, um ihr Passwort zu ändern.

Zu Passwort-Regeln, den unsicheren Sicherheitsfragen und der Bildung sicherer Passwörter habe ich schon vor einiger Zeit etwas geschrieben, dem ist eigentlich nichts hinzu zu fügen. Wichtig erscheint mir (leider) ein anderer Hinweis: Nutzen Sie niemals ein Passwort für mehrere Websites, denn dann betrifft ein Passwortleck gleich mehrere Anwendungen. Wenn Sie Probleme damit haben, sich die vielen Passwörter zu merken, nutzen Sie einen Passwortsafe. Sie könnten natürlich auch mal überlegen, ob Sie vielleicht bei zu vielen Websites angemeldet sind. Wenn sie welche davon nicht mehr nutzen, löschen Sie ihr Konto dort, dann kann auch nichts mehr ausgespäht werden. Sofern der Betreiber Karteileichen löscht und nicht einfach "mitschleppt".

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Mahdi wird zum Bettvorleger, und Passwortlecks sind der Sommerhit 2012

Vorschau anzeigen
Ohne viel Vorrede gleich zum Thema: Mahdi - Ein digitaler Bettvorleger? Keinen großen Kommentar gibt es zu Mahdi. Aus dem einfachen Grund, dass es keine neuen Erkenntnisse darüber gibt. Sie haben richtig gelesen: Außer Ka

Dipl.-Inform. Carsten Eilers am : SQL-Injection im Schnelldurchlauf

Vorschau anzeigen
Laut dem Cloud-Hosting-Anbieter FireHost ist die Zahl der erkannten SQL-Injection-Angriffe zwischen April und Juni 2012 um 69% gestiegen. Während im 1. Quartal 2012 "nur" 277.770 Angriffe abgewehrt wurden, waren es im 2. Quartal 469.983 Angr

Dipl.-Inform. Carsten Eilers am : Authentifizierung: Sichere Passwörter

Vorschau anzeigen
Sichere Passwörter braucht man immer wieder. Wie Sie die erzeugen und sich merken können, erfahren Sie hier. Zuvor geht es aber um die Frage, warum Sie Passwörter nicht für mehrere Dienste nutzen sollten. Kein Recycling f

Dipl.-Inform. Carsten Eilers am : Authentifizierung: Passwortregeln, Teil 2

Vorschau anzeigen
Im ersten Teil dieses zweiteiligen Artikels über Sinn und Zweck von Passwortregeln ging es um das Aufschreiben von Passwörtern. Als nächstes geht es um das Wechseln der Passwörter: Passwörter regelmäßig we

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 5.2013 - PHP-Sicherheit von PHP 4.x bis PHP 5.5

Vorschau anzeigen
Im PHP Magazin 5.2013 ist ein Artikel über die Sicherheit von PHP im Laufe der Zeit erschienen. Und da hat sich einiges getan: register_globals - ab PHP 4.2.0 per Default ausgeschaltet, in PHP 5.3.0 als "deprecated" (veraltet) ein

Dipl.-Inform. Carsten Eilers am : Gibt es eine 0-Day-Schwachstelle in vBulletin oder nicht?

Vorschau anzeigen
Angeblich wurden Server von vBulletin.com und MacRumors vom "Inj3ct0r Team" über eine 0-Day-Schwachstelle in vBulletin kompromittiert. vBulletin glaubt nicht, dass es eine 0-Day-Schwachstelle in vBulletin gibt, bei vBulletin wurde ein unsiche

Dipl.-Inform. Carsten Eilers am : Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1

Vorschau anzeigen
Im Entwickler Magazin 2.2014 ist der erste Teil eines zweiteiligen Artikels über die OWASP Top 10, die zehn gefährlichsten Schwachstellen in Webanwendungen, erschienen. Die Reihenfolge der Schwachstellen ergibt sich aus vier Faktoren

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.