Salz und Hash in Datenbank speichern?

[sx2008]

Sinnvollerweise speichert man zusätzlich noch eine Kennung für die Methode nach der man den Hash berechnet hat.

Code:

A=MD5 mit Salt
B,C,D=zukünftige Hashmethoden

Damit würde man in dem Datenbankfeld z.B. Folgendes speichern

Code:

A:12345:c1a3f0b1c2530e5ed1f160e981ce776d

Sollte die Hashmethode MD5 in Zukunft zu schwach gelten kann man verbesserte Hashfunktionen einsetzen.
Sobald sich ein Benutzer mit Passwort anmeldet kann man sogar im Hintergrund die Zeichenkette mit der besseren Methode abspeichern (Natürlich nur nachdem das Passwort erfolgreich mit der alten Methode überprüft wurde)

[user0815]

@Phoenix: Soll heissen ich erzeuge einen eindeutigen Schlüssel z.B. eine GUID:

Username: Max Mustermann
Passwort: 12345
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

DB Passwort: 12345 + {D365FA88-8442-40B3-82DC-E8D0E0EB0594} = MD5 Hash = dc8dcfc9fd656dca9365b4f7b5fe98f9

Und sichere in der DB das 'neue' Passwort + die GUID:

Username: Max Mustermann
Passwort: dc8dcfc9fd656dca9365b4f7b5fe98f9
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

[Morphie]

Zitat von user0815:

@Phoenix: Soll heissen ich erzeuge einen eindeutigen Schlüssel z.B. eine GUID:

Username: Max Mustermann
Passwort: 12345
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

DB Passwort: 12345 + {D365FA88-8442-40B3-82DC-E8D0E0EB0594} = MD5 Hash = dc8dcfc9fd656dca9365b4f7b5fe98f9

Und sichere in der DB das 'neue' Passwort + die GUID:

Username: Max Mustermann
Passwort: dc8dcfc9fd656dca9365b4f7b5fe98f9
GUID: {D365FA88-8442-40B3-82DC-E8D0E0EB0594}

richtig.

Username: völlig egal!
Passwort: 12345 < Das wird NICHT gespeichert!
Random Salt: 54a4sd88asdasg54rwer7423
Hash: 62e83e4b82f0513deca5f0645f02804f < Das wird gespeichert!

Aus Sicht der Anwendung sieht das dann so aus:
1. Benutzer gibt Username und Passwort ein
2. Programm holt sich den Salt für den Benutzer aus der Datenbank
3. Programm generiert einen MD5-(oder was auch immer)-Hash mittels Passwort + Salt (im oberen Fall also 1234554a4sd88asdasg54rwer7423 = 62e83e4b82f0513deca5f0645f02804f)
4. Programm (oder Datenbank) prüft, ob der generierte Hash mit dem Hash aus der Datenbank übereinstimmt

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

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

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

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

[user0815]

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