Ich löse das immer folgendermaßen:

• Nutzung von Salts (heißt irgendeinen zufälligen String an das Passwort des Benutzers anhängen)
  
• Nutzung von Runden (wie in dem Beispiel, eben pro Benutzer zufällig das Passwort X mal durch sha1 jagen
  

Vorteile von Salts: Ausschaltung von Rainbow-Tables
Vorteile von Runden: Zeit. Es dauert einfach länger, bis das Passwort gehasht ist. Das mag nicht viel sein, summiert sich aber bei Millionen von Kombinationen im Falle eines Bruteforce Angriffes.

Das mehrfache anwenden des ein und selben hash verfahren bring überhaupt keine Sicherheit mehr nur unötige Server auslastung.
Ich empfehle dir Sha256 zu verwenden plus Salt. Am besten den salt aus dem Password selbst generieren so brauchst du den Salt nicht extra speichern.



Schlim das der Blog Beitrag ersteller nicht den Unterschied zwischen einem Hash und Verschlüsseln kennt.

Mfg Splasch

Angenommen das Berechnen eines Hashes dauert 0,1 Sekunden beim Login. Dann dauert der Login eben 0,1 Sekunden länger, weil wir das Passwort 400x hashen. Wen interessiert das?
Das Berechnen eines Rainbow-Tables mit 100 Mio. Einträgen dauert direkt mal 100.000.000*0,1 Sekunden länger, als mit einfachem Hashen. Damit wären wir bei 100 000 000 * 0,1 / 60 / 60 = 2 777,77778 Stunden längerer Berechnungszeit für einen Angreifer. PRO LOGIN. Für jedes Passwort müssen die Berechnungen entsprechend der Rundenzahl sowie des Salts erneut vorgenommen werden. Und die Zeit kann man nutzen, die Kunden entsprechend zu informieren und Maßnahmen ergreifen, die die Schäden zumindest weiter eindämmen können.

Und da das bisschen Rechenleistung bei heutigen CPUs fast nichts mehr kostet, sollte sie einem die zusätzliche Sicherheit durchaus Wert sein.

Und da das bisschen Rechenleistung bei heutigen CPUs fast nichts mehr kostet, sollte sie einem die zusätzliche Sicherheit durchaus Wert sein

Ist unsin bring keine zusätzliche Sicherheit. Wenn du mehr Sicherheit haben willst dann kanst du den Hash danach noch verschlüsseln das würde wenigsten sin machen.

Spätersten jetzt sollte man den Unterschied zwischen Hash und Verschlüsseln kennen!

Siehe auch : mcrypt_create_iv und mcrypt_encrypt

Mfg Splasch

Ps:
Übrings durch mehrfaches Hashen erhöhst du auch deutlich die Kollisionen!

Hash + salt + Verschlüsseln und gut ist.

Wie soll Verschlüsseln jetzt mehr Sinn machen? Die Anwendung muss die Daten ja entschlüsseln können, spätestens bei Zugriff auf die Anwendung erhält ein Angreifer also diesen Key.

Man kann sich jetzt sicher darüber streiten, ob Mehrfachhashing Sinn macht, oder nicht. Aber da gibts schon massig Diskussionen im Internet.

heise.de/security/artikel/Pass…53931.html?artikelseite=2
en.wikipedia.org/wiki/Key_stretching

HEISE schrieb:

Brute-Force-Angriffe lassen sich durch das gewollte Verlangsamen des benutzten Hash-Algorithmus beziehungsweise durch viele Wiederholungen des Hash-Vorgangs unattraktiv machen. Für den Anwender ist die Geschwindigkeit dagegen kaum von Belang: Ob die Prüfung eines eingegebenen Passwortes auf einem System beim Login nun 1 Mikrosekunde oder 1 Millisekunde dauert, merkt er nicht. Einen Passwortknacker würde es aber um den Faktor 1000 ausbremsen – statt 100 Millionen Passwörter pro Sekunde kann er nur noch 100.000 pro Sekunde durchprobieren. Ein Brute-Force-Angriff auf das Kennwort "P4ssW0r7" würde so 48 Jahre statt 18 Tage.

HEISE schrieb:

[..]Das Verfahren ist als Password-Based Key Derivation Function 2 (PBKDF2) standardisiert und findet etwa bei WLANs mit WPA-PSK-Schlüssel Anwendung. Auch Smartphones nutzen PBKDF um Backup-Dateien vor dem Export mit einem Passwort zu verschlüsseln. Auch hier bremst es Knackversuche erfolgreich aus.

Aber nur mal so:
Angenommen, ich hashe "test", dessen Hash 098f6bcd4621d373cade4e832627b4f6 ist. Und jetzt hashe ich diesen 10^4x mit sha1 und Salt. Dann ist die Wahrscheinlichkeit, dass der letzte Hash mit dem eines anderen ROhwertes übereinstimmt, genau so hoch, wie wenn ich das ganze nur 1x hashe. Es wird ja schließlich einfach der erste Hash immer weiter gehasht, so dass Kollissionen nur bei diesem eine Rolle spielen. Eine Kollission im "End-Hash", der in der Datenbank steht, hilft ja nicht weiter - beim Login würde dieser schließlich noch 10^4x gehasht werden.

Dazu auch: phpgangsta.de/passwortmythen-o…ber-nie-zu-sagen-wagtest“ + Kommentare

Ich kann nur den Rat geben auf splasch nicht zu hören.

Das hier könnte aber sehr interessant sein:
phpgangsta.de/schoener-hashen-mit-bcrypt

Wie soll Verschlüsseln jetzt mehr Sinn machen? Die Anwendung muss die Daten ja entschlüsseln können, spätestens bei Zugriff auf die Anwendung erhält ein Angreifer also diesen Key.

Nein wenn du es Schlau machst hat der Angreifer nicht den Key (Das verschlüsselung Passsword). Selbt wenn er Zugang zum Quellcode hat.
Wie das Funktioniert?

Und zwar so das Password wird aus dem Password des User Generiert für die Verschlüsselung. So wird jedes User password erstens mit einem anderen Password verschlüsselt und kann aber immer durch eingabe des Richtigen Passwortes wieder entschlüsselt werden.

Zum Generieren des Verschlüsselung Password überlegst du dir einen Algorytmen.

Zum Beispiel password muss mindesten 6 Zeichen lang sein.

Dann verstauscht du einfach die Zeichen nach einer bestimmten Reihenfolge. Zb 4,1,3,5,2
So ensteht dann nun aus dem Passwort des User: BauernHof
Das verschlüsselungs Password laut dem Algorythmen: eBura

Somit wird dann das Password BauerHof mit dem Password eBura verschlüsselt und nirgendswo im Quellcode erschein das Password für die Verschlüsselung da sich das Password aus dem Password selbst generiert.

Weiteres Beispiel
Andere User sein Password: LiegeStuhl
Verschlüsselungs Password laut dem festgeleten Algorythemn: gLeei

So hast du für jedes Password auch ein anderes Verschlüsselungs Password. Das Entschlüsseln erfolgt dann nach dem selben Prinzip. Der User gibt sein Passwort ein daraus wird wieder mit dem selben Algotytmen das richtige Entschlüsselung Password generiert und geprüft ob die Eingabe richtig war.

Ich hoff das das nun mal so weit verständlich war. Daher macht es sehrwohl dann sin die Passwörter zu verschlüsseln dadurch erhöt sich die Sicherheit enorm statt nun 10 oder 100 mal den selben Hash Anzuwenden.

Selbt wenn nun der Angreifer den Algorythmus kenn kann er damit überhaupt nix anfangen. Die Sicherheit läst sich noch weiter erhöhen wenn man die Algortmus länge ändert so das daraus ein Passwort entsteht mit 16 oder mehr stellen. Im Beispiel hat es nur 5 Stellen der einfach halber zum erklären. (zb. 4,1,3,5,2,3,2,4,5,1 unsw.)

http://www.phpgangsta.de/schoener-hashen-mit-bcrypt

Nun die Email Adresse ins Hash verfahren mit einzubeziehen geht doch etwas weit weg von der Eigentlichen Password Sicherheit. Wenn der User seine Mail Adresse ändere were damit sein Password auch nicht mehr gültig und das kans ja wohl auch nicht sein.

Mfg Splasch

Dazu müsste man auch die Idee in dem Artikel verstehen.

Was wäre das Schlimmste, was er tun kann? Richtig, er ändert das Passwort oder die E-Mail Adresse. Wie kann ich das am effektivsten verhindern? Ganz klar, ich muss ihn zwingen zur Überprüfung das alte Passwort einzugeben. Durch die Kopplung der Hashes an die E-Mail kann ich das gar nicht vergessen