Salz und Hash in Datenbank speichern?

[Zacherl]

Seit PHP 5.5 gibt es sogar integrierte BCRYPT Funktionalität:
http://de3.php.net/manual/en/ref.password.php

Vorteile:
Einheitliches Format in der Datenbank bei Verwendung von password_hash(). Der Hash enthält sowohl eine Kennung des verwendeten Algorithmus (momentan nur BCRYPT unterstüzt), den Salt, als auch eventuelle Parameter (wie beispielsweise der Kostenfaktor beim BCRYPT). Will man später mal den Kostenfaktor erhöhen, oder den Algorithmus wechseln, muss man beim Login nur mit password_needs_rehash() prüfen, ob der Hash in der Datenbank noch passt und ggfls. updaten. password_verify() zieht sich alle benötigten Informationen aus dem hinterlegten String. Somit ist ein fließender Umstieg auf neue Algorithmen (oder höhere Aufwandklassen) möglich. Auch kann man ohne Probleme den Kostenfaktor für Admin Accounts höher ansetzen, als Den für normale User.

Weitere Referenzen:
http://blog.nic0.me/post/63180966453...per-look-under
https://gist.github.com/nikic/3707231

[Valle]

Sagt mal, ist der Witz an einem Salt nicht, dass man auch andere Zeichen in das Passwort bringt, die man sonst üblicherweise nicht als Passwort benutzt? Ich spreche hier vor allem von nicht druckbaren Zeichen?

Wenn ich als Passwort "passwort" habe und als Salz dazu noch "asdf" mache, dann ist "passwortasdf" auch nicht sicherer als vorher. Wenn ich aber als Salz Zeichen nehme, die nicht mal druckbar sind, also chr(random(255)) sozusagen, dann habe ich einen Sicherheitsgewinn.

Oder?

Liebe Grüße,
Valentin

[Zacherl]

Nein. Wenn du md5('password') macht, bekommst du einen Hash. Nun probiere mal den Hash auf z.b. www.md5cracker.org zu finden. Voilla es dauert keine Sekunde, weil die Seite schon riesige Rainbowtables generiert hat.

Wenn du nun das Passwort mit einem Random String saltest, kannst du den reinen Hash sehr wahrscheinlich nicht in einer Rainbowtable finden.

[Valle]

Worauf bezieht sich das Nein?

Mir scheint du hast gerade genau das gleiche gesagt wie ich. Den MD5-Hash zu "passwortasdf" (6461455c74ae87806517b5f552fe988a) kann ich leicht finden, denn er beinhaltet lediglich alphabetische Zeichen. Den MD5-Hash zu "passwort\xe3\xa6\x94\xbf;\x9d\xb2Y\x1a\xe4" (gerade mit obiger Zeilen generieren lassen), werde ich so schnell vermutlich nirgends finden.

Daher meine Theorie: als Salt immer chr(random(255)) (und das so 10-20 Mal, am besten so, dass len(password) + len(salt) >= len(hash)) nehmen. Nicht einfach nur einen Benutzernamen oder sonstige nur alphanumerische Zeichen.

Liebe Grüße,
Valentin

[Namenloser]

Das was Zacherl gesagt hat. Der Angreifer kennt den Salt ja, von daher ist es egal, welche Zeichen er enthält oder wie lang er ist (*). Der Angreifer bruteforced eh nur den Rest nach dem Salt.

Es geht nur darum, vorberechnete Rainbowtables zu verhindern.

(*) Sollte halt nur genug Entropie haben, dass man nicht die Salts schon die Rainbowtable miteinbeziehen kann.

[cookie22]

Trotzdem nein.

Es geht nicht darum ein Passwort sicherer zu machen. Das Salt ist einzig und allein zur Randomisierung da.

Hash(passwort + asdf) = 123;
Hash(passwort + sdfg) = 567;
Hash(passwort + dfgh) = 890;

Dreimal das gleiche Passwort ergibt drei verschiedene Checksummen. Das ist der Sinn der Salts.

[Valle]

Mh, versteh ich nicht.

Natürlich kennt der Angreifer den Salt. Aber eine Rainbow Table wird immer unpraktischer, je länger sie wird und je größer der Zeichensatz ist. Also ist es doch in meinem Interesse, den zu hashenden String möglichst lang zu machen und viele verschiedene Zeichen einzufügen. Oder wo liegt mein Denkfehler?

Liebe Grüße,
Valentin

[Namenloser]

Ja, so ist das schon richtig. Aber in deinem Post („Sagt mal, ist der Witz an einem Salt nicht, dass man auch andere Zeichen in das Passwort bringt, die man sonst üblicherweise nicht als Passwort benutzt? Ich spreche hier vor allem von nicht druckbaren Zeichen?“) klang das anders. Es ist auch egal, wie groß der Zeichenvorrat des Salts ist, du könntest auch nur Ziffern verwenden und ihn dafür länger machen...

[Valle]

Zitat von NamenLozer:

Ja, so ist das schon richtig. Aber in deinem Post („Sagt mal, ist der Witz an einem Salt nicht, dass man auch andere Zeichen in das Passwort bringt, die man sonst üblicherweise nicht als Passwort benutzt? Ich spreche hier vor allem von nicht druckbaren Zeichen?“) klang das anders. Es ist auch egal, wie groß der Zeichenvorrat des Salts ist, du könntest auch nur Ziffern verwenden und ihn dafür länger machen...

Ah, okay. Dann hab ich das wohl irgendwie doof formuliert.

Momentan reicht es wohl, ihn einfach nur länger zu machen. Aber momentan reicht auch RSA 2048. Dennoch nutzen leute mehr. Also dachte ich, kann ich es auch einfach mit den Salts übertreiben. Zukunftssicherer, sozusagen.

Liebe Grüße,
Valentin

[cookie22]

Zitat von Valle:

Mh, versteh ich nicht.

Natürlich kennt der Angreifer den Salt. Aber eine Rainbow Table wird immer unpraktischer, je länger sie wird und je größer der Zeichensatz ist. Also ist es doch in meinem Interesse, den zu hashenden String möglichst lang zu machen und viele verschiedene Zeichen einzufügen. Oder wo liegt mein Denkfehler?

Liebe Grüße,
Valentin

Es ist aber nicht die Aufgabe des Salts das zu hashende Passwort zu verlängern oder zu verbessern, es geht einzig und allein um die Randomisierung. Die Entropie sollte vom Passwort selbst kommen. Mit einem Salt machst du ein schlechtes Passwort nicht besser.