PHP/MySQL: Passwörter richtig verschlüsseln?

[BartTheDevil89]

Hallo,

ich bins mal wieder. Diesmal mit einem weiteren Thema. Passwörter richtig zu verschlüsseln.
Normal ist ja, dass Passwörter mit md5 verschlüsselt werden und gespeichert.
Allerdings gilt md5 ja schon lang als nicht mehr sicher und eben leicht zu entschüsseln.
Da ich allerdings noch nie wirklich über Alternativen gelesen habe, wollte ich gern mal eure Meinung einholen.

Wie wird heute am besten verschlüsselt? Denn auf der einen Seite sollte ja die Verschüsselung sicher sein, allerdings auf der anderen Seite auch ressourcensparend, da ja die Verschüsselung bei jeder Passworteingabe wieder durchgeführt werden muss.

Vielen Dank für die Hilfe

[theHacker]

MD5 ist kein Verschlüsselungs-, sondern ein Hashverfahren

Nimm SHA1 und alles wird gut.

[ice-breaker]

sha512 + einen sicheren salt, am besten dynamisch je einen pro user (um rainbow-tables gegen den gleichen salt zu vermeiden)

hash-chains, also zb 10mal hashen ist auch eine ganz nette, um bruteforce noch mehr ad absurdum zu führen

Zitat von theHacker

Nimm SHA1 und alles wird gut.

wielange sha1 aber noch die angrife aushält ist fraglich, ich würde da lieber was aus der sha2-familie nehmen (sha224 - sha512)

[Banane]

Zitat von ice-breaker

hash-chains, also zb 10mal hashen ist auch eine ganz nette, um bruteforce noch mehr ad absurdum zu führen

Damit verringert man aber theoretisch die Sicherheit von Passwörtern mit mehr als 20 Byte (bei einem 160-Bit Hashverfahren, wie z.B. SHA1; wenn man davon absieht, dass das ein Passwort i. d. R. nicht aus allen möglichen Bytekombinationen besteht).

[Tyrell]

Zitat von theHacker

Nimm SHA1 und alles wird gut.

SHA-1 ist mittlerweile auch schon gebrochen.
edit: Zumindest theoretisch. Aber wozu soll man auf ein sinkendes Schiff setzen...

[ice-breaker]

Zitat von Banane

Damit verringert man aber theoretisch die Sicherheit von Passwörtern mit mehr als 20 Byte (bei einem 160-Bit Hashverfahren, wie z.B. SHA1; wenn man davon absieht, dass das ein Passwort i. d. R. nicht aus allen möglichen Bytekombinationen besteht).

in der theorie schon, ja da hast du recht, aber das mehrfachhashing behindert mathematische Angriffe auf die Algorithmen.

Während es noch "einfach" ist bei einem md5-Hash eine Kollision zu finden, wenn man Ausgangsmaterial hat, was den Daten ähnelt indem man Dummy-Daten hinzufügt wird das immer komplexer durch Hash-Chains, denn da der Input nun einen festen Wert hat (32 Byte md5-hash + salt) lassen sich keine Kollisionen über genannte Methode mehr erstellen.

Das macht das Kollisionen finden über 10 Stufen deutlich schwerer und ist mit den bisherigen Angriffen auch nicht machbar.

[BartTheDevil89]

Oha....da hab ich ne Diskussion losgelöst^^

Also wenn ich mal zusammenfasse sollte es sha160-512 sein. (Empfehlung? Am besten ein Mittelding?)
Aber der Punkt mehrfach-Hash (sollte doch bedeuten, dass ich einfach den Hash, dann nochmal durchführe, bzw. bei 10 mal halt 10 mal den String durchjage?) scheint ja noch stark diskutiert zu werden.

[LasMiranda]

Mehrfachhash erhöht Kollisionen.

[ice-breaker]

Zitat von BartTheDevil89

Also wenn ich mal zusammenfasse sollte es sha160-512 sein. (Empfehlung? Am besten ein Mittelding?)

"sha160" wie du es nennst ist sha-1 und ist nicht mehrzu empfehlen, ich würde gleich eine Empfehlung für sha512 aussprechen, der Algorithmus wird wohl momentan am längsten halten

Zitat von LasMiranda

Mehrfachhash erhöht Kollisionen.

klar, aber diese sind mit allen momentan veröffentlichten PoCs nicht zu berechnen, da diese sich auf das Hinzufügen von Dummydaten beschränken was mit Mehrfachhashing nunmal nicht möglich ist.

[BartTheDevil89]

Ok...also sha512 und mehrfach-Hash(2x reicht, oder?) sollte ne gute Lösung sein?

[ice-breaker]

Einfach-Hashen ist bei Sha512 vollkommen ausreichend.

Ich würde das mehrfach-hashen mehr einen "Trick" nennen für Algorithmen bei denen man mitlerweile in einigermaßen angemessenem Rechenaufwand Kollisionen errechnen kann.

[ice-breaker]

Nochmal nen Nachtrag (habe etwas gebraucht das wiederzufinden)

Die crypt (Unix) Implementation von md5 ($1$) nutzt ebenfalls, rehashing, da hatte ich mir das abgeschaut:

First the passphrase and salt are hashed together, yielding an MD5 message digest. Then a new digest is constructed, hashing together the passphrase, the salt, and the first digest, all in a rather complex form. Then this digest is passed through a thousand iterations of a function which rehashes it together with the passphrase and salt in a manner that varies between rounds. The output of the last of these rounds is the resulting passphrase hash.

Crypt: MD5 based scheme

[Tyrell]

Mehrfachverschlüsseln und Mehrfachhashen (auch mit verschiedenen Funktionen) ist in den allermeisten Fällen totaler Schwachsinn. Bei gleichen Verfahren vergrößert sich i.d.R nie der Schlüsselraum und bei unterschiedlichen Verfahren kann es sogar passieren, dass er sich verkleinert.

[muh_kuh]

Zitat von Tyrell

Mehrfachverschlüsseln und Mehrfachhashen (auch mit verschiedenen Funktionen) ist in den allermeisten Fällen totaler Schwachsinn. Bei gleichen Verfahren vergrößert sich i.d.R nie der Schlüsselraum und bei unterschiedlichen Verfahren kann es sogar passieren, dass er sich verkleinert.

wie kommt du den da drauf ?
es macht es doch sicher z.B.
Passwort : geld
Sha1 : 013960e6ca8513f47f79a63e9cf73f1a0fd2a037
sha1 (Username # SHA1)
87eef4812f754d180e09d26b950201853f73398b
wo wird da der Raum kleiner ?
so ist ein einfaches Passwort (Geld) doch sicher
da es plötzlich 45 Zeichen sind die schon mal dran waren

[theHacker]

Einfache Mathematik:
SHA1: [0; ∞] → [0; 2¹⁶⁰-1]

SHA1∘SHA1: [0; ∞] → [0; 2¹⁶⁰-1],

wobei der erste Aufruf [0; ∞] → [0; 2¹⁶⁰-1],
aber der zweite Aufruf nur noch [0; 2¹⁶⁰-1] → [0; 2¹⁶⁰-1] macht.

Das meinte Tyrell mit Verkleinerung des Schlüsselraums

Ein einfaches Passwort "Geld" mit 32bit wird auf 160bit "verschwierigt".
Was ist aber mit komplexeren Eingaben, die mehr als 160bit haben? Diese werden "einfacher" und führen zu Kollisionen.