Salz und Hash in Datenbank speichern?

[Morphie]

@cookie22
Kommt ein Angreifer z.B. durch SQL-Injection an die Login-Tabelle (Username, Hash, Salt), kann er sein Dictionary entsprechend salzen...
Wenn der Hash aber durch weitere nebendaten (z.B. dem gehashten Salt) nochmals gesalzen wird, ist der Aufwand wesentlich höher.
Man müsste also genau wissen, WIE gesalzen wird. Ein einfaches Password+Salt ist meiner Meinung nach zu einfach.

[cookie22]

Darum sollte man aber besser so etwas wie bcrypt nutzen. Das erhöht den Aufwant erheblich und wurde genau zu diesem Zweck entwickelt.

[generic]

Zitat von Morphie:

@cookie22
Kommt ein Angreifer z.B. durch SQL-Injection an die Login-Tabelle (Username, Hash, Salt), kann er sein Dictionary entsprechend salzen...

Der Trick ist eine Hashfunktion zu wählen die viel Power benötigt.
Das stellt im Betrieb auch kein Problem dar, da ein Login meist nur einmalig passiert.

Mehr Power kann man z.B. erreichen, indem man den Hash 100 mal mit den Salt hasht.
Cracker-Bremse

[BUG]

Zitat von generic:

Der Trick ist eine Hashfunktion zu wählen die viel Power benötigt.

Also eben eine wie bcrypt oder scrypt. Es ist generell ein Fehler, so etwas selbst zu entwerfen.
Hier gibt es übrigens eine (imho gute) Übersicht über die Verfahren.

Troy Hunt hat das Problem mal am ASP.NET Membership Provider verdeutlicht. Lesenswert und sehr anschaulich.

[milos]

Wie wäre es wenn man zwischen jedem char ein bisschen verschiedenes Salz streut?

[Namenloser]

Zitat von milos:

Wie wäre es wenn man zwischen jedem char ein bisschen verschiedenes Salz streut?

Ob du das Salz vorne, hinten oder irgendwie zwischendrin einstreust, sollte bei einer kryptographischen Hashfunktion prinzipiell egal sein.

[cookie22]

Mir ist immer noch unbegreiflich, warum ihr da alle selbst rumbastelt, anstatt bcrypt, scrypt oder in Gottesnamen auck pbkdf2 zu benutzen. Diese Verfahren sind alle erprobt und sicher.

[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