[master2005]

Guten Tag,

reicht es aus, wenn ich

hash('sha256', $password . $salt)

verwende das password mit sha256 + salt in die DB speichere und bei der Abfrage das eingegeben password vergleiche mit sha256 + salt aus der DB?

Salt = ist ein zufallsstring

[°EraZoR°]

Ich muss sagen, dass ich davon nicht so viel Ahnung habe, aber wenn du den Salt zusammen mit dem Passwort speicherst, dann kannste den Salt auch weglassen..

Weil wer das verschlüsselte Passwort aus der DB ausliest, kann auch gleich den Salt mit auslesen..
Ich würde das eher fest in den Code packen...
Entweder immer den gleichen Salt für alle Benutzer in einer Config speichern..
Oder, was vermutlich auch besser ist, den Salt anhand eines Algorithmus zu generieren..
zB die MD5 vom Benutzernamen oder ähnliches..
Den kann man dann natürlich auch generieren, aber dafür muss der Angreifer das erstmal wissen wie der Salt generiert wird...

MfG

[master2005]

Ja aber MD5 gilt ja als geknackt.

Man kann ja wie ich es mir erlesen habe, mit dem hash von sha256 + Salt nichts anfangen. Weil man es nicht entschlüsseln kann.


Mann kann einen Wert z.B. das Passwort mit dem Salt und sha256 verschlüsseln und dann vergleichen.

http://www.webmasterpro.de/coding/ar...speichern.html

[Murdoc]

sicher ist relativ.

wenn deine db gehackt wird und der salt da mit drin liegt isser nutzlos.

ein fester salt ist ebefalls nutzlos. sobald man den raus hat (z.b. via shell/lfi) kann man jedes passwort cracken.

[master2005]

Wie würdest Du denn vorgehen Murdoc ?

[Murdoc]

hätte ich ne bessere lösung, dann würde ich sie sicherlich dazuschreiben

ich schreibe derzeit den salt mit in die datenbank und mach noch ein paar andere dinge die ich jetzt nicht umbedingt ausführlich beschreiben möchte.

als tipp: mach es so umständlich wie möglich, dann verlieren cracker die lust. knackbar ist es aber dennoch.
schau dir zusätzlich mal mcrypt an: http://www.php.net/manual/de/ref.mcrypt.php

[Timer]

Zitat von °EraZoR°

Ich muss sagen, dass ich davon nicht so viel Ahnung habe, aber wenn du den Salt zusammen mit dem Passwort speicherst, dann kannste den Salt auch weglassen..

Weil wer das verschlüsselte Passwort aus der DB ausliest, kann auch gleich den Salt mit auslesen..

der salt ist nicht dazu da, das passwort unknackbar zu machen. es soll nur verhindert werden, dass der hash mit hilfe einer rainbowtable schnell geknackt wird.

das salt sollte daher auch nicht statisch sein, damit es keinen sinn macht eine rainbowtable mit diesem salt zu generieren.

gegen schlechte passwörter kann ein salt dann auch nichts machen

[dreamax]

Zitat von master2005

Ja aber MD5 gilt ja als geknackt.

hab ich da was verpasst?


Wenns ihm um die Passwortsicherheit (z.B. durch Bruteforce) geht, soll er SHA512 nehmen und ein "langes" Passwort vorschreiben

[MArc]

Jungs, was redet ihr da?
Der Salt ist nicht nutzlos, auch nicht, wenn er immer an der selben Stelle injected wird.

Der Salt ist dafür da, dass der Angreifen für jedes Salz eine eigene Rainbow-Table generieren muss.
Je nachdem welcher Algo, wie komplex das Salz ist, wie viele Runden etc benutzt wurde/n ist es nahezu unmöglich, so alle Passwörter in einem Menschenleben zu knacken.

Wie Timer schon sagt, muss das Salz aber auf jeden fall _nicht_ statisch sein, sonst ist er in der Tat nutzlos.

Am besten Du benutzt eine Chiffrierung des Hashes/Pws mit einem statischen Schlüssel in den Config und ein random Salz für jeden Hash. Falls Du md5 nutzen willst, pack den algo noch in paar Runden ein. Hat folgenden Vorteile:
a) Muss der Angreife neben einer SQL-Injection auch zugriff auf's Filesystem haben, um die PWs zu entschlüsseln
b) Dauert die Generierung der Rainbowtables erhebtlich länger bei abgefahrenen custom salt-schemas, da die meisten rainbowtables da draußen nicht auf allen salz-kombinationen aufsetzen. (Meist sogar nur die standard Dinger wie <pw>+<salt>, <salt>+<pw>, <salt>+<pw>+<salt> etc)
c) (falls a) nicht greift) und der Angreifer selbst die rainbowtable anlegen muss, dauert es je nach algo und runden _erheblich_ länger.

Als Code-Beispiel:
https://github.com/KrynLabs/Kryn.cms...class.php#L753

[Murdoc]

und wo genau wiederspricht sich das mit meiner aussage? ^^

fester (statischer) salt -> nutzlos.
zufälliger salt mit in der db bei nem hack -> nutzlos.

das einzige was im raum steht ist eben der aufwand und die fähigkeit entsprechende stellen im code zu finden und zu verstehen.

um es nochmal zusammenzufassen:

man kann es den crackern nur erschweren. z.b. mit nem algo der um einiges länger braucht als md5/sha1/sha256 etc. z.b. (wie oben erwähnt) nen aufwendigen algo mittels mcrypt oder eben mehrere runden. dann sind ein paar stunden schnell mal tage bei dict-attacks.

ich hab die letzten tage mal nen interessanten artikel dazu gelesen.
http://codahale.com/how-to-safely-store-a-password/

[theQuest]

Ich mache es so: Bei jedem erfolgreichem Passwort ändert sich der Salt. Welcher Salt zum Passwort gehört ist eine Kombination aus Cookie und DB.

In der DB gibt es eine Salt-Tabelle (key, salt). Key wird beim User als Cookie gespeichert. Wenn sich der User nun einloggt wird anhand des Salts im Cookie versucht, das Passwort zu überprüfen.

Wenn erfolgreich: Neuer Salt mit neuem Key > Cookie auch neu (alten löschen).

Falls nun ein User keinen Cookie hat, geht das über eine gesonderte Seite (falls ein User also auf Account XYZ zugreifen will, aber keinen Cookie hat (oder einen falschen) wird er auf einen anderen Login geschickt, wo er danach den Login via Mail bestätigen muss).

Zusätzlich stehen mehrere Methoden der Verschlüsselung zur Auswahl. Diese Information wird allerdings noch beim User in der Datenbank gespeichert. Ob es was bringt, ka.

Dies ist sehr umständlich und nicht bei allen Projekten zu nutzen. Wenn es aber sicher sein soll, ist dies ein Vorschlag.

[phraser]

Wie wäre denn eine Mischung aus Salt in der Datenbank und Salt auf der Festplatte?

Nicht jeder, der eine SQL Injection beherrscht, hat auch die Möglichkeit an eine Shell bzw an die Dateien auf dem Webserver zu kommen.
Wenn man also beim Login einmal mit dem SALT in der DB und danach diesen Hash wieder mit Salt von der HD verschlüsselt, wäre das Ganze wahrscheinlich dreimal so langsam wie die nur Datenbank Methode, aber man hätte ein gewisses weiteres Maß an Sicherheit geschaffen.
Der Hash Prozess bzw. das Salt auslesen (aus Dateien) ist zwar wirklich sehr langsam, würde aber nur beim Passwort ändern oder Login genutzt werden, also bei einem Forum z.B. nicht 1000mal die Sekunde..

[badloader]

PHP-Code:

$localsalt = 'salZindiewunde';
$usersalt = randomstring($length = 5); // mit sonderzeichen
$password = $post->password; // passwörter strenger limitieren

$password = 'b2312_00:' . md5($localsalt . md5($usersalt . $password));

$user = new ORM::factory('user');
$user->password = $password;
$user->salt = $usersalt;
$user->save(); 


Murdoc hat schon recht: Das sollte einen "guten" Hacker/Cracker nicht aufhalten. Und moderne Bruteforce Programme auch nicht. Aber alleine zu verstehen, wie das PW generiert wird und das Bruteforce Programm einzustellen, bringt die meisten an ihre Grenzen (siehe einschlägige Foren!). Sie werden bei einer 0815 Seite einfach keine Lust haben das PW zu knacken. Aufwand lohnt sich nicht.
Außerdem brauchen sie lokalen Zugriff und DB Zugriff. So hältst du die meisten auf.

[theQuest]

Noch als Tipp: Auf jeden Fall die Anzahl der Versuche limitieren. Nach 5 Loginversuchen IP sperren.

[MArc]

Zitat von Murdoc

und wo genau wiederspricht sich das mit meiner aussage? ^^

Hier

Zitat von Murdoc

zufälliger salt mit in der db bei nem hack -> nutzlos.

Sofern der Angreifer mittels Rainbowtable ran muss, muss er fuer jeden Salt eine eigene generieren. Damit ist ein zufaelliger Salt also definitiv nicht nutzlos.


@phraser, +1, genau mein Reden.
Ja, zumal die Einlog-Geschwindigkeit in der Tat oft keine grosse Rolle spielt. Der Login darf ruhig auch seine halbe Sekunde dauern. Umso komplexer die Berechnung umso langsamer sind Bruteforce attacken.
Falls es aber doch performancekritisch ist, kann man den Schlüssel auch entsprechend cachen: http://www.tutorials.de/blogs/marc/1...benchmark.html

[Murdoc]

gezielte angriffe (z.b. auf administratoren) sind dennoch ohne probleme möglich.

zudem kann der angreifer die klartext-passwörter der rt auch zur laufzeit hashen mit dem gespeicherten salt. dauert halt ein wenig länger (GPU?)

vielleicht kann das jemand mit mehr ahnung mal aufklären.

[badloader]

Hier bitte sehr. Gut kenne ich mich damit aber nicht aus
http://hashcat.net/oclhashcat-plus/#performance

Zitiere mal die interessanten Stellen:

Hash Type, PC1
MD5 4739.3M c/s
Joomla 4281.4M c/s

Joomla wird so generiert:

1. Generierung einer Zufallszeichenfolge $rand
2. $salt = md5($rand)
3. $crypt = md5($klartextpasswort:$salt)
4. Speichern in der Datenbank von $crypt:$salt

Somit ist festzuhalten:
Zwischen MD5 und Joomla liegen zum Bruten 10% Geschwindigkeitsverlust bei dem Programm und dem einen Beispiel PC. 10% Ist kein Problem letztendlich.

Quellen:
http://www.joomlaportal.de/allgemein...lung-salt.html
http://www.joomlaportal.de/allgemein...wort-hash.html

[dreamax]

Zitat von badloader

Hier bitte sehr. Gut kenne ich mich damit aber nicht aus
http://hashcat.net/oclhashcat-plus/#performance

hab ich 8 posts über dir gepostet. Deshalb sag ich ja SHA512.

Sind auf gescheiten systemen auch kein 10%.