Salz und Hash in Datenbank speichern?

[mjustin]

Verstehe ich den Wikipedia Artikel richtig: Salt und Hash des Passwortes werden (in zwei Feldern) der Datenbanktabelle gespeichert? Meistens liest man ja, dass in der Datenbank nie der Klartext sondern ein Hash abgelegt wird. Mit dem Salt wären es dann zwei Felder in der Benutzertabelle.

[Mikkey]

Unter Salt ist nicht der Klartext des Passworts zu verstehen, sondern eine Zufallszeichenfolge, die mit dem eigentlichen Passwort verwürfelt den Hash ergibt.

[gammatester]

Wer spricht von Klartext? Das Salt wird mitgespeichert. Das ist ein öffentlicher Prefix für's Hashen und soll Dictionary-Attacken vermeiden (helfen).

[BUG]

Es entspricht zwar nicht der 1. NF, aber Salt und Hash können durchaus auch in einer Zeichenkette gespeichert werden.
Aber du solltest überlegen, ob du nicht lieber auf Adaptive Key Derivation Functions wie PBKDF2 oder bcrypt ausweichst.

[user0815]

Zu einem Passwort gehört ja auch ein Username, in der Datenbank werden somit Username + Passwort als Hash gesichert.

Username: Max Mustermann
Passwort: 12345

Der MD5 Hash von 12345 ergibt: 827ccb0eea8a706c4c34a16891f84e7b
Gibt man 827ccb0eea8a706c4c34a16891f84e7b in google ein so kann man sehen das dies der Hash zu 12345 ist.

Ein bisschen Salz dazu: c1a3f0b1c2530e5ed1f160e981ce776d

Passwort + Salz: 12345 + c1a3f0b1c2530e5ed1f160e981ce776d als MD5 Hash = 96f853c0ab69c35f2e40dede5a5e9d97

Username: Max Mustermann
Passwort: 96f853c0ab69c35f2e40dede5a5e9d97

Das Salz ist also nicht in der DB zu sichern, zumindest nicht offensichtlich.
Man könnte auch einen Hash bilden aus Username + Passwort + Salz + Length(Username) + usw…

Gibt der Username jetzt sein Passwort ein so muss der Hash wieder berechnet werden, stimmen berechneter Hash und gesicherter Hash aus der DB überein so stimmt das Passwort.

[Morphie]

Den Usernamen als Salt zu verwenden halte ich für eine schlechte Idee... Was, wenn Max Mustermann mal einen anderen Nachnamen annimmt? Der Username wird also geändert und das Passwort ist nicht mehr gültig...

[Phoenix]

Zitat:

Zitat von user0815 (Beitrag 1231391)

Das Salz ist also nicht in der DB zu sichern, zumindest nicht offensichtlich.

Doch.

idealerweise gibt es ja pro Datensatz einen eigenen Hash.
Hintergrund ist einfach, den Aufwand eines Angriffs hoch zu treiben. Haben alle Hashes den gleichen Salt (z.B. in der Config eines Programmes), so reicht es, das Dictionary einmalig zu salten und dann muss nur noch einmalig nach Matches gesucht werden. Heraus kommen alle User mit bekanntem Password.

Ist jedes Passwort mit einem eigenen Salt gehasht, so muss das Dictionary für jeden Datensatz mit dem jeweiligen Salt gehasht werden um dann nach Matches zu suchen. Im Prinzip muss man dann den Aufwand von oben pro Passwort treiben, was sich dann irgendwann nicht mehr lohnt.

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

Zitat von user0815 (Beitrag 1231420)

@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:

Zitat von Morphie (Beitrag 1231425)

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

Zitat von Morphie (Beitrag 1231434)

@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:

Zitat von Morphie (Beitrag 1231434)

@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:

Zitat von generic (Beitrag 1231443)

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:

Zitat von milos (Beitrag 1231834)

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

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

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:

Zitat von NamenLozer (Beitrag 1231883)

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

Liebe Grüße,
Valentin

[cookie22]

Zitat:

Zitat von Valle (Beitrag 1231882)

Mh, versteh ich nicht. :oops:

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.