Benutzerpasswörter sicherer speichern

veröffentlicht am 19. Oktober 2012

Immer wieder tauchen Meldungen über massenhaft geleakte Klartext Passwörter im Internet auf. Das erschreckende daran: häufig stammen die Daten aus Datenbanken größerer Unternehmen, die vermutlich die Passwörter im Klartext oder einfach nur als Hash gespeichert hatten (auch wenn es selten zugegeben wird). Dabei ist es eigentlich ganz einfach, die Passwörter zumindest etwas sicherer abzulegen. Dieser Artikel zeigt auf, welche Methoden zur Verfügung stehen, um die Benutzer besser zu schützen.

Klartext Passwörter

Die unsicherste Methode, Passwörter abzulegen, besteht natürlich darin, die Passwörter im Klartext abzulegen. Bekommt ein Angreifer (das kann auch einfach nur ein unzufriedener Mitarbeiter sein) Zugriff auf die Daten, kann er sich ohne Probleme Zugang zu diversen Diensten verschaffen, denn leider verwenden viele Benutzer immer wieder ein und dasselbe Passwort für verschiedenste Dienste (siehe Tipps zu sicheren Passwörtern).

Eine Datenbank Tabelle mit Klartext Passwörtern könnte zum Beispiel so aussehen (die gezeigten Passwörter gehören übrigens laut Umfragen zu den zehn am häufigsten genutzten Passwörtern):

E-Mail Passwort
max.mustermann@example.com 123456
thomasmueller@example.com passwort
maria-schmidt@example.com schatzi
kathrin-kraemer@example.com passwort

Passwörter hashen

Schon besser ist es, wenn der Anbieter die Passwörter nur als Hash abspeichert. Dabei wird das Klartext Passwort über eine Einwegfunktion so umgewandelt, dass das Klartext Passwort nur unter sehr hohem zeitlichen Aufwand zurück berechnet werden kann. Häufig wird hierfür MD5 (gilt nicht mehr als sicher) oder SHA eingesetzt. Die eben gezeigte Tabelle würde bei Verwendung von SHA-256 so aussehen:

E-Mail Hash
max.mustermann@example.com 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92
thomasmueller@example.com 33c5ebbb01d608c254b3b12413bdb03e46c12797e591770ccf20f5e2819929b2
maria-schmidt@example.com b7e95959a7a8e65aa9dd6ea86cbf66da6982098b87cc754bcc8690cd532df286
kathrin-kraemer@example.com 33c5ebbb01d608c254b3b12413bdb03e46c12797e591770ccf20f5e2819929b2

Der Vorteil besteht darin, dass ein Angreifer die Passwörter nicht mehr ohne weiteres entschlüsseln kann. Dieses Verfahren hat jedoch zwei Probleme. Zunächst können Benutzer mit demselben Passwort leicht identifiziert werden, da derselbe Hash erzeugt wird (Benutzer 2 und 4 in der Tabelle). Außerdem können einfache Passwörter schnell über so genannte Rainbow Tables ermittelt werden. Hierbei werden alle möglichen Klartext Passwörter mit ihrem entsprechenden Hash verknüpft, sodass einfach der Hash nachgeschlagen werden muss, um an das Klartext Passwort zu kommen.

Passwörter salten und hashen

Aufgrund der eben genannten Probleme sollten Passwörter deshalb vor dem Hashen mit einem Salt (einer Zeichenkette) verknüpft werden.

Die schwächste Form des Salt ist eine statische, d.h. für jedes Passwort gleiche, Zeichenkette. Problem dieser Variante ist, dass eine Rainbow-Table wieder relativ schnell erzeugt werden kann, wenn der Salt bekannt ist.

Deshalb sollte als Salt lieber eine dynamische Zeichenkette verwendet werden. Um Speicherplatz zu sparen, kann man beispielsweise den Benutzernamen (in diesem Beispiel die E-Mail Adresse) verwenden. Die Tabelle von eben würde bei Verwendung der E-Mail Adresse als Salt wie folgt aussehen (die mittlere Spalte dient nur der Veranschaulichung):

E-Mail Passwort + Salt Hash
max.mustermann@example.com 123456max.mustermann@example.com af5514a8f207246f5399f1d76a95451cc29a204877f5aedbd128be3580ea171d
thomasmueller@example.com passwortthomasmueller@example.com 398c8ce8577426988225a709807f0e6d1e1aaf128ad6243e3028212e8049edb5
maria-schmidt@example.com schatzimaria-schmidt@example.com dafa9aef4655c391905e8aa8c5b052c5bc1bc4445dae752762b03068d13b7852
kathrin-kraemer@example.com passwortkathrin-kraemer@example.com 8abba9e1fdf40bae321c80efb22ae37fabeba5ca0f5bcdbec6c964b7cd029235

Diese Variante hat lediglich den Nachteil, dass der Benutzer seine E-Mail Adresse nicht ändern kann, ohne das Passwort erneut als Klartext einzugeben, denn das Klartext Passwort muss erneut mit einem Salt versehen, gehashed und abgespeichert werden. Deshalb macht eine weitere Spalte mit einem Zufallswert, der bestenfalls über alle Einträge hinweg einzigartig ist, durchaus Sinn.

Bei dieser Variante müsste der Angreifer die Rainbow Table für jeden einzelnen Benutzer erneut berechnen, was einen enormen Zeitaufwand bedeutet und dem Anbieter bei Bekanntwerden einer Sicherheitslücke zusätzliche Zeit verschafft, um natürlich erst einmal alle Passwörter zu ersetzen und die Benutzer zu benachrichtigen (damit diese ihr Passwort bei allen Diensten ändern, bei denen dasselbe Passwort verwendet wurde).

Eigene Passwort Chiffrierung vor dem Hash

Wem die Salt Variante noch nicht sicher genug ist, kann einen eigenen Algorithmus zum Verknüpfen des Passwortes mit dem Salt implementieren. Beispielsweise könnte man abwechselnd je einen Buchstaben des Passworts und des Salt aneinander hängen. Sobald einer der beiden Teile zu Ende ist, wird der Rest des anderen Teils angehängt. Das könnte so aussehen:

E-Mail Passwort + Salt Hash
max.mustermann@example.com 1m2a3x4.5m6ustermann@example.com 6661f76fcc204425ba2cef959add3e66a4a95702c9dc829269e7c440d22d156c
thomasmueller@example.com ptahsosmwaosrmtueller@example.com c23fedadeae91be9cf14551629e37016a18a65d6ea178ab72bc116b8120c2755
maria-schmidt@example.com smcahraitaz-schmidt@example.com 404e3d0e6053750d9260b109a5c7f56a64d676c38f06a3776f72521779d92cc2
kathrin-kraemer@example.com pkaastshwroirnt-kraemer@example.com fc749f40c3e2d796a284cb44ccedfc305e579a8bd737bafde8f12c119adf5aa4

Dieser Algorithmus kann natürlich beliebig kompliziert aufgebaut werden und bestenfalls sogar dynamisch auf bestimmte Prämissen reagieren (beispielsweise einen anderen Algorithmus wählen, wenn die Quersumme der Passwort Prüfsumme größer 5 ist). Somit müsste der Angreifer nicht nur für jedes Passwort eine eigene Rainbow Table erstellen, sondern auch noch die verwendete Chiffrierung knacken (oder Zugriff auf den Quelltext haben).

Fazit

Es ist eigentlich ganz einfach, die Passwörter der Benutzer sicherer (im Sinne von schwerer entschlüsselbar) abzulegen. Vollständige Sicherheit wird es nie geben, jedoch kann man sich durch die eben gezeigten Verfahren einen deutlichen Zeitvorteil verschaffen, zumindest wenn ein Datenleck selbst erkannt wird.

Um die Sicherheit der Benutzer weiter zu steigern, könnte man bestimmte Anforderungen an das Passwort stellen (den Benutzer im Prinzip zu einem sicheren Passwort zwingen) und den Benutzer auffordern, sein Passwort nach einer gewissen Zeitspanne zu ändern.

Und jetzt gebe ich den Ball an euch weiter: fallen euch weitere Maßnahmen ein, um die Sicherheit noch weiter zu verbessern?

Kommentare

Moin,

cooler Artikel! Ich habe vor kurzem einen Artikel über knacken von Passwörtern gelesen. Modernste Grafikkarten können binnen Sekunden Millionen von Hashes auflösen.

Zitat:
„It’s a high-end consumer graphics card that retails for about $500 in Australia. I bought one the other day in part to drive more screens than my old one permitted and in part to understand more about what goes into cracking hashes. This is where hashcat comes in. You see, using hashcat to leverage the power of the GPU in the 7970 you can generate up to 4.7393 billion hashes per second. That’s right, billion as in b for “bloody fast”.“

http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html

Kommentar #1 von Jan am 14. November 2012


Hallo Jan, Hallo Patrick,

Troy Hunt bezieht sich auf einfache Hashes und die Problematik war längere Zeit Fachleuten bekannt. Eine zusätzliche Möglichkeit ist es das Passwort mehrfach durch ein Hash-Algorithmus durchzujagen, etwa so:

echo passwort+salt|sha512sum|sha512sum|sha512sum|sha512sum

Das Passwort ist hier schon nach dem ersten Durchlauf 129 Zeichen lang und das Knacken mit Brute-Force mit bisher allen auf der Welt produzierten GPU’s konvergiert leicht gegen Unendlich :-) Viel interessanter sind da Wörterbuchangriffe die ein Passwort faktisch erraten, weil sich niemand kryptisches merken kann und das hier erwähnte Salten verhindert das schon recht wirksam.

Ein interessanter Beitrag dazu:

http://www.heise.de/security/artikel/Passwoerter-unknackbar-speichern-1253931.html

Kommentar #2 von Bernhard am 24. November 2012


Gute Zusammenfassung zu dem Thema. Werde ich mir so in die Bookmarks packen, falls mich mal jemand danach fragt. ;)

Kurze Ergänzung noch:
„…Nachteil, dass der Benutzer seine E-Mail Adresse nicht ändern kann…“
Deshalb benutzt man gern das Erstellungsdatum des Anwenders als Salz. Außerdem ist das Verwenden von Hash-Algorithmen ratsam, die nicht wie z.B. MD5 auf Performance optimiert sind. Für den Anwender macht es schließlich keinen merkbaren Unterschied, ob es nun eine 1/1000 Sekunde oder eine 1/10 dauert. Für den Angreifer während des Brute-Force-Vorgangs aber schon.

Kommentar #3 von Gerrit am 28. November 2012


Hinterlasse einen Kommentar