Salz und Hash in Datenbank speichern?

[cookie22]

Zitat von Morphie:

...Will man das System noch verbessern, kann man das Passwort mehrmals salzen (z.B. Salt + Password + md5(Salt))

Was soll das bringen? Ein Salt reicht.

[user0815]

Oder das von @BUG genannte 'PBKDF2' noch hinzufügen.

[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.

[Namenloser]

Stimmt, so wird es kein bisschen sicherer.

Was man allerdings machen kann, ist

Delphi-Quellcode:

password := 'blume1234';
salt := irgendwas möglichst zufälliges;

tmp := salt;
for i := 1 to n do
begin
  password := hash(tmp + password);
  tmp := hash(tmp) + password;
end;
// passwort und salt werden jetzt in der datenbank gespeichert.

Damit kann man den Zeitaufwand fürs Knacken um das n-fache steigern. Hoffe ich hab jetzt keinen Denkfehler in dem Code... bin kein Kryptoexperte. Aber auf jeden Fall gibt es so eine Methode... bcrypt und Co. arbeiten glaube ich auch so ähnlich.

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...
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.

Das wäre Security by Obscurity, nicht unbedingt die beste Strategie, aber als Ergänzung u.U. in Ordnung. Besser finde ich es da allerdings, einfach noch einen zweiten, globalen Salt außerhalb der Datenbank, z.B. in einer Config-Datei zu speichern. Dann verwendet man hash(globaler_salt + salt + passwort). So reicht es nicht, wenn der Angreifer nur Zugriff auf die Datenbank hat.

[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.