Warum Sie sich Sorgen machen sollten, wenn die Kennwortdatenbank eines Dienstes durchgesickert ist

„Unsere Passwortdatenbank wurde gestern gestohlen. Aber keine Sorge: Ihre Passwörter wurden verschlüsselt. “ Wir sehen regelmäßig solche Aussagen online, einschließlich gestern von Yahoo. Aber sollten wir diese Zusicherungen wirklich zum Nennwert nehmen?

Die Realität ist, dass die Passwortdatenbank ein Problem gefährdet, unabhängig davon, wie ein Unternehmen versucht, es zu drehen. Es gibt jedoch einige Dinge, die Sie tun können, um sich zu isolieren, unabhängig davon, wie schlecht die Sicherheitspraktiken eines Unternehmens sind.

Wie Passwörter gespeichert werden sollen

So sollten Unternehmen Passwörter in einer idealen Welt speichern: Sie erstellen ein Konto und geben ein Passwort ein. Anstatt das Passwort selbst zu speichern, generiert der Dienst aus dem Passwort einen «Hash». Dies ist ein eindeutiger Fingerabdruck, der nicht rückgängig gemacht werden kann. Zum Beispiel kann sich das Passwort «Passwort» in etwas verwandeln, das eher wie «4jfh75to4sud7gh93247g …» aussieht. Wenn Sie Ihr Kennwort eingeben, um sich anzumelden, generiert der Dienst einen Hash daraus und prüft, ob der Hash-Wert mit dem in der Datenbank gespeicherten Wert übereinstimmt. Der Dienst speichert Ihr Passwort zu keinem Zeitpunkt selbst auf der Festplatte.

Um Ihr tatsächliches Kennwort zu ermitteln, muss ein Angreifer mit Zugriff auf die Datenbank die Hashes für allgemeine Kennwörter vorberechnen und dann prüfen, ob sie in der Datenbank vorhanden sind. Angreifer tun dies mit Nachschlagetabellen – riesigen Listen von Hashes, die mit Passwörtern übereinstimmen. Die Hashes können dann mit der Datenbank verglichen werden. Beispielsweise würde ein Angreifer den Hash für «password1» kennen und dann prüfen, ob Konten in der Datenbank diesen Hash verwenden. Wenn dies der Fall ist, weiß der Angreifer, dass sein Kennwort «Kennwort1» lautet.

Um dies zu verhindern, sollten Dienste ihre Hashes „salzen“. Anstatt einen Hash aus dem Passwort selbst zu erstellen, fügen sie vor dem Hashing eine zufällige Zeichenfolge am Anfang oder Ende des Passworts hinzu. Mit anderen Worten, ein Benutzer würde das Passwort «Passwort» eingeben und der Dienst würde das Salt hinzufügen und ein Passwort hashen, das eher wie «Passwort35s2dg» aussieht. Jedes Benutzerkonto sollte über ein eigenes eindeutiges Salt verfügen. Dadurch wird sichergestellt, dass jedes Benutzerkonto einen anderen Hashwert für sein Kennwort in der Datenbank hat. Selbst wenn mehrere Konten das Kennwort «password1» verwenden würden, hätten sie aufgrund der unterschiedlichen Salzwerte unterschiedliche Hashes. Dies würde einen Angreifer besiegen, der versucht hat, Hashes für Passwörter vorab zu berechnen. Anstatt Hashes generieren zu können, die für jedes Benutzerkonto in der gesamten Datenbank gleichzeitig gelten, müssten sie eindeutige Hashes für jedes Benutzerkonto und dessen eindeutiges Salt generieren. Dies würde viel mehr Rechenzeit und Speicherplatz in Anspruch nehmen.

Aus diesem Grund sagen Dienste oft, dass sie sich keine Sorgen machen sollen. Ein Dienst, der geeignete Sicherheitsverfahren verwendet, sollte angeben, dass gesalzene Kennwort-Hashes verwendet wurden. Wenn sie einfach sagen, dass die Passwörter «gehasht» sind, ist das besorgniserregender. LinkedIn hat zum Beispiel ihre Passwörter gehasht, aber sie haben sie nicht gesalzen – es war also eine große Sache als LinkedIn 2012 6,5 Millionen gehashte Passwörter verlor.

Schlechte Passwortpraktiken

Dies ist nicht die schwierigste Sache zu implementieren, aber viele Websites schaffen es immer noch, es auf verschiedene Weise durcheinander zu bringen:

• Speichern von Passwörtern im Klartext: Anstatt sich mit Hashing zu beschäftigen, können einige der schlimmsten Straftäter die Passwörter einfach im Klartext in eine Datenbank kopieren. Wenn eine solche Datenbank kompromittiert wird, sind Ihre Passwörter offensichtlich kompromittiert. Es wäre egal, wie stark sie waren.
• Hashing der Passwörter, ohne sie zu salzen: Einige Dienste können die Passwörter hashen und dort aufgeben und sich dafür entscheiden, keine Salze zu verwenden. Solche Kennwortdatenbanken wären sehr anfällig für Nachschlagetabellen. Ein Angreifer kann die Hashes für viele Kennwörter generieren und dann prüfen, ob sie in der Datenbank vorhanden sind. Dies kann für jedes Konto gleichzeitig geschehen, wenn kein Salt verwendet wird.
• Salze wiederverwenden: Einige Dienste verwenden möglicherweise ein Salt, verwenden jedoch möglicherweise dasselbe Salt für jedes Benutzerkontokennwort. Dies ist sinnlos – wenn für jeden Benutzer dasselbe Salt verwendet würde, hätten zwei Benutzer mit demselben Kennwort denselben Hash.
• Verwendung von kurzen Salzen: Wenn nur wenige Ziffern verwendet werden, können Nachschlagetabellen erstellt werden, die jedes mögliche Salz enthalten. Wenn beispielsweise eine einzelne Ziffer als Salz verwendet würde, könnte der Angreifer leicht Listen von Hashes erstellen, die jedes mögliche Salz enthalten.

Unternehmen erzählen Ihnen nicht immer die ganze Geschichte. Selbst wenn sie sagen, dass ein Passwort gehasht (oder gehasht und gesalzen) wurde, verwenden sie möglicherweise nicht die Best Practices. Gehen Sie immer auf Nummer sicher.

Andere Bedenken

Es ist wahrscheinlich, dass der Salt-Wert auch in der Passwortdatenbank vorhanden ist. Das ist nicht so schlimm – wenn für jeden Benutzer ein eindeutiger Salt-Wert verwendet würde, müssten die Angreifer massiv CPU-Leistung aufwenden, um all diese Passwörter zu brechen.

In der Praxis verwenden so viele Menschen offensichtliche Passwörter, dass es wahrscheinlich einfach wäre, die Passwörter vieler Benutzerkonten zu ermitteln. Wenn ein Angreifer beispielsweise Ihren Hash kennt und Ihr Salt kennt, kann er leicht überprüfen, ob Sie einige der am häufigsten verwendeten Kennwörter verwenden.

Wenn ein Angreifer es für Sie heraus hat und Ihr Passwort knacken möchte, kann er es mit brutaler Gewalt tun, solange er den Salzwert kennt – was er wahrscheinlich tut. Mit lokalem Offline-Zugriff auf Kennwortdatenbanken können Angreifer alle gewünschten Brute-Force-Angriffe ausführen.

Andere persönliche Daten gehen wahrscheinlich ebenfalls verloren, wenn eine Kennwortdatenbank gestohlen wird: Benutzernamen, E-Mail-Adressen und mehr. Im Falle des Yahoo-Lecks wurden auch Sicherheitsfragen und -antworten durchgesickert – was es bekanntlich einfacher macht, den Zugriff auf das Konto einer anderen Person zu stehlen.

Hilfe, was soll ich tun?

Was auch immer ein Dienst sagt, wenn seine Passwortdatenbank gestohlen wird, es ist am besten anzunehmen, dass jeder Dienst vollständig inkompetent ist, und entsprechend zu handeln.

Verwenden Sie Kennwörter nicht auf mehreren Websites. Verwenden Sie einen Passwort-Manager, der für jede Website eindeutige Passwörter generiert. Wenn ein Angreifer feststellt, dass Ihr Kennwort für einen Dienst «43 ^ tSd% 7uho2 # 3» lautet und Sie dieses Kennwort nur auf dieser einen bestimmten Website verwenden, hat er nichts Nützliches gelernt. Wenn Sie überall dasselbe Kennwort verwenden, können diese auf Ihre anderen Konten zugreifen. Auf diese Weise werden die Konten vieler Personen «gehackt».

Wenn ein Dienst kompromittiert wird, müssen Sie das dort verwendete Kennwort ändern. Sie sollten das Passwort auch auf anderen Websites ändern, wenn Sie es dort wiederverwenden – aber Sie sollten dies nicht in erster Linie tun.

Sie sollten auch die Zwei-Faktor-Authentifizierung in Betracht ziehen, die Sie auch dann schützt, wenn ein Angreifer Ihr Kennwort erfährt.

Das Wichtigste ist, Passwörter nicht wiederzuverwenden. Kompromittierte Passwortdatenbanken können Sie nicht verletzen, wenn Sie überall ein eindeutiges Passwort verwenden – es sei denn, sie speichern etwas anderes Wichtiges in der Datenbank, wie z. B. Ihre Kreditkartennummer.

Bildnachweis: Marc Falardeau auf Flickr, Wikimedia Commons