PHP Salt&Pepper

[max_1234]

Ich bin relativ neu in der Webentwicklung und schreibe gerade ein kleines CMS.
Beim Salting/Peppering bin ich auf ein paar kleine Verständnisprobleme gestoßen

Ich habe mir verschiedene Infos im WEB und auch direkt von anderen Entwicklern geholt, allerdings scheint es mir so, dass einige die Begriffe Salt und Pepper verschieden intepretieren, oder zumindest die Reihenfolge ist nicht dieselbe.

Was genau ist nun SALT und PEPPER?

Ich intepretiere es aktuell so:
Salt = "1234"
Passwort = "Pass"

Salted = md5(Password . Salt)

Viele machen es aber anders, in etwa so:
Salted = md5(md5(Pass) . Salt)

Wie genau geht man nun vor?
Und welches Prinzip wird beim Pfeffern angewandt?

mfg,
Max

 

[Yuuri]

Ist vollkommen Hupe, hauptsache du bringst einen Salt mit ein, der jeweils unterschiedlich ist. Und am besten nimmst du auch nicht MD5, sondern mindestens SHA-1 (ist auch schon teilweise "unsicher", besser eine Stufe höher mit SHA-256 o.ä.) oder nutzt gleich BCrypt. Keine Ahnung ob es gut ist, aber hier mal der erste Treffer in Google: http://www.phpgangsta.de/schoener-hashen-mit-bcrypt

 

[max_1234]

Ok, dann erstelle ich mir mal meine eigene Definition:

Salt:
Eine zufällige (aber dem Server bekannte) Zeichenfolge wird dem Passwort angehängt, egal ob das Passwort bereits mit MD5/SHA-x bearbeitet wurde - und im Anschluss daran erneut mit MD5/SHA-x gehasht.

Pepper:
Es wird immer diesebe Zeichenfolge verwendet, um Passwörter (auch bereits gehashte) zu salten, wobei die Zusatz-Zeichenfolge nicht im selben Speicherort wie der Passwort-Hash liegen darf.

mfg,
Max

 

[ice-breaker]

Keine Ahnung ob es gut ist, aber hier mal der erste Treffer in Google: http://www.phpgangsta.de/schoener-hashen-mit-bcrypt

Bcrypt ist easy zu nutzen im gestern erschienen PHP 5.5 drinne, und wer kein PHP 5.5 hat, für den gibt es einen Nachbaue in PHP.

Salt:
Eine zufällige (aber dem Server bekannte) Zeichenfolge wird dem Passwort angehängt, egal ob das Passwort bereits mit MD5/SHA-x bearbeitet wurde - und im Anschluss daran erneut mit MD5/SHA-x gehasht.

stimmt so ungefähr, korrekter wäre einfach die Definition das im Prozess des Hashings eine für das Passwort des Nutzers zufällige Zeichenfolge mitbenutzt wird.
Das muss nämlich nicht durch anhängen passieren (erlaubt diverse Angriffe) sondern kann z.B. besser mit hmac gemacht werden.
Ein hmac_sha1 als Beispiel teilt z.B. auch nicht die selben Angriffe wie sha1 und ist eine ganze Ecke sicherer.

Pepper:
Es wird immer diesebe Zeichenfolge verwendet, um Passwörter (auch bereits gehashte) zu salten, wobei die Zusatz-Zeichenfolge nicht im selben Speicherort wie der Passwort-Hash liegen darf.

Gilt das gleiche wie vorher, aber dann ist es korrekt, jup

 

[Daaron]

Fazit: Mit bcrypt wird man auf jeden Fall glücklicher als mit md5 oder sha, egal ob der Server nun schon 5.5 hat oder nicht (die Antwort lautet meist: oder nicht. Kenne keine Stable-Distri, die das mit bringt)

 

[Kanibal]

Die PHP crypt()-Funktion bringt bcrypt seit 5.3 mit: CRYPT_BLOWFISH.

 

[ice-breaker]

korrekt, aber du musst dann auch selbst die Salts erzeugen, Logik schreiben um zu prüfen ob du das Passwort mit einem neuen Kostenfaktor erneut hashen musst usw...
Die von mir verlinkte Bibliothek nimmt einem das alles ab, in dem es die neuen Funktion für altes PHP implementiert.

Und die Salts zu erzeugen ist gar nicht so einfach, ich spreche da aus Erfahrung, ich habe bevor es den Entwurf zu der PHP 5.5 PAsswort Hashing Library gab soetwas schon auf Bcrypt-Basis geschrieben. Es gibt da dann noch verschiedene genutzte Bcrypt-Libraries und eigentlich darf das letzte Zeichen des Salts nur 3-4 verschiedene Werte haben (veränderter Base64), fast alle Implementierungen stören sich nicht, wenn man den Fehler macht, bis auf ich glaube FreeBSD war das damals.
Die Aussage gilt für pre-5.3 als PHP noch keine eigene Bcrypt-Implementierung nutzte und auf die vom OS angewiesen war.
Trotzdem bleibt die Salt-Erzeugung noch als "Problem", mt_rand() erzeugt ja nun auch keine wirklich guten Zufallszahlen, will man auf der Basis Salts erzeugen? Nein?! Gut, dann wird es nämlich etwas komplexer an gute Random-Bytes zu kommen [1] [2].