Passwörter richtig Salten
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
algorithmus
auge
code
datenbank
frage
gedanke
idee
interessieren
nutzen
nutzer
packen
sinn
string
test
theoretische kollision
url
verwenden
vorgehen
wahl
zeichen
-
Hey Leute,
Ich hatte Freitag eine Diskusion mit einem Kollegen, wie man Passwörter am besten salted. Es ging darum, dass ich als normaler Cracker, der ne Datenbank knackt, über einen Rainbowtable sehr viele Passwörter nachschauen kann. Bis 20 Stellen ist da bestimmt schon alles geknackt.
Darum hatten wir überlegt, wie man effizient auch gegen soetwas vorgehen kann. Natürlich kann ich einen Salt von 40 Zeichen davor und 40 Zeichen dahinter packen, dies wäre allerdings in sofern uninteressant, da bei einem Klau auch der Code evtl gezogen werden könnte, und so auch die Salt Strings gefunden würden. Dann könnten speziell für uns neue Rainbowtables geschrieben werden, die einfach alle Strings zwischen diese 2 Packt und fertig. Das wäre also nicht sicher genug, in unseren Augen.
Dannach haben wir überlegt, was wäre mit doppeltem Hashen? Wir schreiben einfach:
$hash = hash( “haval128″ , hash( “whirlpool” , $passwort , false ) , false );
(dass wir nicht MD5 nutzen, sondern einen ebenfalls 32 Zeichen gebenden Hash wie haval128 oder tiger128 war schon von forn herein klar. haval128 hat zwar eine theoretische Kollision, tiger128 ist aber Performancelastiger, die Wahl ist jedem selbst überlassen, gibt ja einige Alternativen)
So würde aus dem Passwort ein 128Zeichen langer Hash enstehen, den es dann zu unhashen gilt. Zudem hat man mit haval128 oder tiger128 andere Algos als MD5, die Rainbowtabelle müsste also erst neu geschrieben werden, aber für 2 Hashes. Dabei ist der Gedanke, dass der Hash in MD5 von "TEST" ein anderer ist als der in Haval128, und, das Passwort durch den ersten Hash, whirlpool, auf 128 Zeichen gebracht wird.
Eine dritte Variante war ein Partial-Salting. Ich hatte hier mal eine Funktion geschrieben, wie wir es uns überlegt haben: https://gist.github.com/sateffen/6549659. Dabei werden Saltstücke nicht nur an Ende und Anfang angefügt, sondern auch in den String hineingefügt. Der Algo ist recht simple, aber wir glaube, doch recht effektiv.
Nun wollte ich mal Fragen, wie ihr Passwörter salted, oder allgemein speichert. Was haltet ihr von dem Algorithmus, den ich in nem Gist hier verlinkt habe. Ist sowas überhaupt Sinnvoll? Würd mich mal interessieren. Vielleicht haben wir ja noch Ideen übersehen, die viel besser als unsere Gedanken sind.
Liebe Grüße -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
ich habe es so gelernt, dass man nicht nur im code salted sonder vorallem mit einem salt der in klartext in der Datenbank steht. Und zwar pro User einen anderen, der "neben" dem Passwort steht.
Der ist natürlich auch mit weg, wenn die Datenbank geknackt wird, aber (und das ist der Sinn hinter dem Salten) in diesem Fall müsste für jedes Passwort eine neue Rainbowtable erstellt werden, was sehr zeit intensiv wäre. -
ggamee schrieb:
Darum hatten wir überlegt, wie man effizient auch gegen soetwas vorgehen kann. Natürlich kann ich einen Salt von 40 Zeichen davor und 40 Zeichen dahinter packen, dies wäre allerdings in sofern uninteressant, da bei einem Klau auch der Code evtl gezogen werden könnte, und so auch die Salt Strings gefunden würden. Dann könnten speziell für uns neue Rainbowtables geschrieben werden, die einfach alle Strings zwischen diese 2 Packt und fertig. Das wäre also nicht sicher genug, in unseren Augen.
Eben genau darin besteht der Sinn eines Salts, dass man keine bereits vorhandenen Rainbow-Tables verwenden kann. Denn um solche Tabellen zu berechnen benötigt man viel Zeit. Und wenn man dann noch pro User z.B. die User ID in den Salt einbaut, ist das ganze doch recht unattraktiv für einen Angreiffer.
Bei der Wahl eine Hash-Algorithmus muss man nicht unbedingt auf die Performance achten, im gegenteil, ein Algorithmus, der länger braucht ist eigentlich besser, da man somit nicht so viele Strings durchprobieren kann.
Dannach haben wir überlegt, was wäre mit doppeltem Hashen? Wir schreiben einfach:
$hash = hash( “haval128″ , hash( “whirlpool” , $passwort , false ) , false );
(dass wir nicht MD5 nutzen, sondern einen ebenfalls 32 Zeichen gebenden Hash wie haval128 oder tiger128 war schon von forn herein klar. haval128 hat zwar eine theoretische Kollision, tiger128 ist aber Performancelastiger, die Wahl ist jedem selbst überlassen, gibt ja einige Alternativen)
So würde aus dem Passwort ein 128Zeichen langer Hash enstehen, den es dann zu unhashen gilt. Zudem hat man mit haval128 oder tiger128 andere Algos als MD5, die Rainbowtabelle müsste also erst neu geschrieben werden, aber für 2 Hashes. Dabei ist der Gedanke, dass der Hash in MD5 von "TEST" ein anderer ist als der in Haval128, und, das Passwort durch den ersten Hash, whirlpool, auf 128 Zeichen gebracht wird.
Nun wollte ich mal Fragen, wie ihr Passwörter salted, oder allgemein speichert. Was haltet ihr von dem Algorithmus, den ich in nem Gist hier verlinkt habe. Ist sowas überhaupt Sinnvoll? Würd mich mal interessieren. Vielleicht haben wir ja noch Ideen übersehen, die viel besser als unsere Gedanken sind.
Persönlich verwenden ich gerne sha256 oder sha512 und setze einfach einen String vor das Kennwort, ggf. auch mit UserID. Somit fallen weder Mehrfach verwendete Kennwörter auf noch ist es besonders Effektiv eine Rainbow-Table anzulegen. Damit bleibe dann nur für jeden User einzeln durchzuprobieren. -
Ich würde mir da weniger gedanken machen, wer passworter auslesen kann, der braucht sie meistens nicht, da er besimmt auch auf die anderen Daten zugreifen kann. Ich persönlich benutzte übrigens sha256 mit einem festen salt vorne und hinten.
-
Ich brauche das zwar recht selten, aber meine Variante ist die, das Passwort mit dem Salt mehrmals zu hashen:
$hash = $password.$salt; for($i = 0; $i < 5000; $i++) { $hash = hash('sha512', $hash.$password.$salt); }
Die Idee, jedem Nutzer einen Salt zuzuordnen, finde ich eigentlich sehr gut. Wenn man das noch einbauen würde, wären die Passwörter relativ schwer zu knacken. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
