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

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]

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]

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]

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]

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

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]

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[sup]160[/sup]-1]

SHA1∘SHA1: [0; ∞] → [0; 2[sup]160[/sup]-1],

wobei der erste Aufruf [0; ∞] → [0; 2[sup]160[/sup]-1],
aber der zweite Aufruf nur noch [0; 2[sup]160[/sup]-1] → [0; 2[sup]160[/sup]-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.

 

[Tyrell]

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

Wenn ich als Eingabe für den SHA1 eine Ausgabe des SHA1 nehme, reduziert sich die Anzahl der möglichen Eingaben für den letzten SHA1 von theoretisch unendlich vielen auf eine (immerhin noch sehr große) endliche Zahl. Der Raum, indem ich Kollisionen suche, wird dadurch um einiges kleiner, weil ich weiß, dass meine Kollision auf jeden Fall eine SHA1-Ausgabe ist.
Das Passwort selber hingegen interessiert mich natürlich nicht, das brauche ich auch nicht rauszukriegen. Ich benötige einfach eine Zeichenkette, die denselben Hash erzeugt.
Bei deiner Variante weiß ich zusätzlich, dass diese Zeichenkette ebenfalls ein Hash ist. Dadurch wird die Sicherheit erheblich eingeschränkt, was mathematische Angriffe angeht.
Die Variante mit dem Salt kann man machen, um die Sicherheit gegen Rainbowtables zu erhöhen.
Wenn man es wirklich sicher haben möchte, sollte man sich überlegen, die Daten zu verschlüsseln.

edit: Das entspricht dem, was theHacker in den beiden eingerückten Zeilen geschrieben hat.


edit2: Der Schlüsselraum bezog sich auch eher auf Verschlüsselungsverfahren und nicht auf Hashing.

 

[ice-breaker]

Ja, gebe ich euch vollkommen Recht, aber hier mal zum nachvollziehen was ich meine:

String: geheim
Salt: ilu3nel7
Sha1-Wert: 8d0aef0721264c433a7018edd8788b8d35682db1

Bis dahin noch alles normal.
Nun mache ich den Schritt nochmal.
String: 8d0aef0721264c433a7018edd8788b8d35682db1
Salt: ahi7mis1
Sha1-Wert: 776be6db2ec7373b21d2067eb1eea5b58d0da357

So was ich nun ausdrücken will, die momentanen mathematischen Angriffe funktionieren eben auf solche Konstrukte nicht, denn die versuchen auf den Hash "bb5167924a24aca90c3566c63b9b31539d0a57fe" zukommen indem sie einen String mit Dummy-Daten solange gezielt weiterfüttern, bis der Hash-Wert rauskommt. Es gibt aber keinen Angriff der dies über mehrere Ebenen kann, denn man kann ja nur den Ausgangsstring "geheim" modfizieren und muss so eine Kollision über 2 Ebenen berechnen (dabei ist eine Ebene schon schwer genug). Dadurch dass wir einen anderen Salt bei dem 2. Hashing auch wieder verwenden haben wir keine statische Länge sodass Angriffe auf Grund von der Länge des Ausgangsmaterials beim 2. Hashing erleichtert würden.

 

[MiD]

Das Wort "Kollision" fällt in dieser Diskussion ziemlich oft, aber was ist das genau? Ich kann mir vieles drunter vorstellen, aber nichts konkretes. Ich hoffe mir, kann jemand den Begriff "Kollision" im Zusammenhang mit Passwörtern erklären.

Liebe Grüße

 

[jackmaster]

Das Wort "Kollision" fällt in dieser Diskussion ziemlich oft, aber was ist das genau? Ich kann mir vieles drunter vorstellen, aber nichts konkretes. Ich hoffe mir, kann jemand den Begriff "Kollision" im Zusammenhang mit Passwörtern erklären.

Wenn zwei (oder mehr) unterschiedliche Strings bei der Anwendung einer Hash-Funktion in den selben Ausgabestring überführt wurden nennt man das Kollision.

Der Kontext ist damit also nicht "Passwörter", sondern "Hashing".

Konkret geht es darum, dass wenn jemand Passwörter speichert, indem er z.B. eine Hash-Funktion darauf anwendet (und im simplen Fall sonst nichts tut) und Du nun an diesen Hashwert gelangst, sowie außerdem weißt, welche Hash-Funktion verwendet wurde, Du durch das Wissen um einen String, der den selben Hashwert erzeugt, einfach diesen String statt des eigentlichen Passwortes nehmen könntest, um einen Login durchzuführen. Somit ist es also nicht mehr erforderlich, irgendwie an das tatsächliche Passwort zu gelangen, sondern es "reicht", irgendeinen String zu finden, der den gleichen Hashwert hat, wie das echte Passwort.

 

[theHacker]

Das Wort "Kollision" fällt in dieser Diskussion ziemlich oft, aber was ist das genau?

Eine Kollision ist, wenn

f(x) = f(y) für x ≠ y.
​

Ich häng noch ein Beispiel dran. Die Hashfunktion f sei wie folgt definiert:

f: ℤ[sup]+[/sup][sub]0[/sub] → {0, 1, 2, 3}
f: x ↦ x mod 4
​

f berechnet also den Rest der Ganzzahlsdivision zu 4.
Wenden wir die Hashfunktion auf ein paar Eingaben an:

f(0) = 0
f(1) = 1
f(2) = 2
f(3) = 3
f(4) = 0 Kollision!
​

f(0) = f(4), aber 0 ≠ 4.

In diesem Fall ist klar, dass alle Eingaben, wo ein Vielfaches von 4 aufaddiert wird, Kollisionen auslösen, da

f(x) = f(x+4k) ∀k∈ℕ[sub]0[/sub].
​

Zu den Passwörter zurück heißt dass, es gibt unterschiedliche Passwörter (Eingaben), die aber denselben Hash-Funktionswert liefern. Ein Angreifer will nicht unbedingt dein Passwort finden. Ihm reicht es, ein Passwort zu finden, was denselben Hashwert hat, wie dein Passwort.

Für SHA1 ist der Definitionsbereich der Hashfunktion (|[0; ∞]| = ∞) sicher größer ist, als der Wertebereich der Hashfunktion (|[0; 2[sup]160[/sup]-1]| = 2[sup]160[/sup] < ∞), gibt es unendlich viele Kollisionen.
Ein Angreifer braucht nur eine von den unendlichen vielen zu finden.

Wäre dein Passwort 1544172846, so würde mit der Hashfunktion f es auch reichen, wenn ich mich einfach mit 42 einloggen würde, da

f(1544172846) = f(42) = 2​

ist.