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:
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".
Trackbacks
Dipl.-Inform. Carsten Eilers am : Mahdi wird zum Bettvorleger, und Passwortlecks sind der Sommerhit 2012
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : SQL-Injection im Schnelldurchlauf
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Authentifizierung: Sichere Passwörter
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Authentifizierung: Passwortregeln, Teil 2
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 5.2013 - PHP-Sicherheit von PHP 4.x bis PHP 5.5
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Gibt es eine 0-Day-Schwachstelle in vBulletin oder nicht?
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: Entwickler Magazin 2.2014 - Die OWASP Top 10, Teil 1
Vorschau anzeigen
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.