Statt md5(str) - Das, was heise vorschlug in einf. Code gegossen

[Jörg Reinholz]

Hallo,

Nämlich einfachen also verständlichen Code, bei dem nicht jeder die Dokumentation und reichlich Drittquellen bemühen muss.

Einfacher Code ist nicht notwendig produktionsreifer Code und schon gar nicht kryptographisch sicherer Code.

Nochmal. Seit wann bedeutet "Das was heise vorschlug, läuft übrigens auf etwas wie das hier heraus:", dass es sich um produktionsreifen Code handelt?

Habe ich dargestellt, dass es darum geht, WIE (sic!) man Passwörter zum Zweck des Speicherns salzt und mehrfach hashed?

• Meine Ansicht: Das genau habe ich sehr wohl getan!

Ein grundlegendes Verfahren in Pseudocode zu beschreiben ist natürlich in Ordnung. Das hat der von dir verlinkte Heise-Artikel ja auch getan, das tut auch jeder Grundlagenartikel zu bcrypt, PBKDF2 oder Key Stretching im Allgemeinen.

Ich schrieb über dem Code: "Das was heise vorschlug, läuft übrigens auf etwas wie das hier heraus:"
Noch mal: "ETWAS WIE DAS HIER"

Wenn hier Code gepostet wird, muss man damit rechnen, dass ihn jemand kopiert. Er ist für die »Ewigkeit« konserviert und in Suchmaschinen auffindbar. Was meinst du, warum ich hier die Sicherheitslücken im Ausgangsposting moniert habe.

Die sind in offenbar zur späteren Produktivität enthalten.

Nicht, um irgendwen zu ärgern, vorzuführen

Aber Worte wie "Wenn man von Krypto wenig Ahnung hat, sollte man besser Bibliotheken und Funktionen von Leuten verwenden, die wissen, was sie tun." verwenden ...

Habe ich damit irgend jemanden gesagt, er soll es so und nicht anders machen?

Die Vehemenz, mit der du deine selbstgebaute Funktion verteidigt hast und gültige Kritik heruntergespielt hast, ist schon erstaunlich.

Das mache ich gar nicht. Ich wehre mich dagegen, dass und in welchen Ton mein Beispiel - ohne ernst zu nehmende Konstruktive Kritik - runter gemacht wird.

Wie gesagt, einfach mal nur Funktionsnamen und bestenfalls den Link zum englischem(!) Handbuch  in die Runde zu werfen und - ohne jegliche wichtige Ergänzungen - auszusagen, diese zu verwenden sei sicher - mein Skript aber von jemanden, der wenig Ahnung habe das finde ich nicht nur "Scheiße", das ist es auch.

Habe ich was falsch gemacht, also ich funktionierenden PHP-Code präsentierte?

• Meine Ansicht:  Nein. Die Menschen lernen am besten an praktischen Beispielen.

Ein sinnvolles *praktisches* Beispiel wäre Code, der nach aktuellen Stand sicher, produktionsreif und direkt kopierbar ist.

Nochmal: Ich habe den Code nie als praktisches Beispiel bezeichnet. Es steht sogar deutlich drin, dass Teile fehlen, z.B. zur Überprüfung des Passwortes. Ich habe ihn als einfachen Code bezeichnet.

Habe ich was falsch gemacht, also ich auf sehr spezielle und bei vielen noch nicht einmal verfügbaren Funktionen verzichtete?

• Meine Ansicht:  Nein. Ich wollte ja zeigen, WIE es PRINZIPIELL geht.

Es geht sowohl prinzipiell als auch praktisch mit password_hash() + password_compat ab der PHP-Version 5.3.7. Warum nicht das zeigen?

Aus dem Handbuch:
string password_hash ( string $password , integer $algo [, array $options ] )

Fein, den Algorithmus darf man wieder selbst angeben, als options['salt'] darf man dann den hash wieder selbst übermitteln - das läuft also auf das selbe hinaus wie hash_pbkdf2() - und ist eine Blackbox, weil wieder keiner weiß, was das Ding treibt. Was $options['cost'] bewirkt erschliest sich aus der Dokumenattion auch nach dem Folgen von einem halben Dutzend Links nicht. Nur dass es zwischen 4 und 31 liegen soll. und das in PHP 5.3.7 was repariert wurde. Soweit zu "ausgereifte Bibliotheken bzw. Funktionen".

Und ergo ist password_hash() insoweit dann auch unbrauchbar, weil das Ergebnis deshalb nicht ohne weiteres in anderen Sprachen zu erzeugen oder zu überprüfen ist.

Einem so schlechten Zufallsgenerator, der hier binnen etlicher Billionen Versuche einen salt zweimal erzeugt, den gibt es auch in PHP - jenseits auf die Version beschränkter Bugs - nicht.

Es geht nicht um das mehrmalige Erzeugen von Salts. rand() nutzt einen Kongruenzgenerator, um aus einem gegebenen Seed deterministisch Folgezahlen zu erzeugen. Ist der Seed bekannt, sind sämtliche folgenden Zahlen herleitbar. Das ist etwas anderes als ein nicht-deterministischer, kryptografisch sicherer Zufallsgenerator, der z.B. im Linux-Kernel hinter /dev/(u)ranpassword_hashdom steckt.

Und? Ist der seed bekannt? Ist er es - oder ist er es nicht? Er ist es nicht. Alles hinter "Ist der Seed bekannt" ist damit unzutreffend, also sind sämtliche folgenden Zahlen NICHT herleitbar.

jetzt sollte man /dev/random auch nutzen. Am besten über plattformübergreifende und ausgereifte Bibliotheken bzw. Funktionen im PHP-Kern.

So lange mir keiner erklärt wo der PHP-Kern "/dev/random" unter Windows findet habe ich viel Mühe dieser Funktionen als "plattformübergreifend" anerkennen. Zumal sich mir nicht erschließt, wieso ich dann nicht gleich das Original ( file_get_contents('/dev/random', false, NULL, 0, 32) ) sondern so ziemlich neue Funktionen (aus PHP 5.3 - das auch noch nicht auf jedem Webserver läuft...) wie "openssl_random_pseudo_bytes()" nehmen soll.

Und wenn password_hash() vor 5.3.7 Probleme hatte, woher soll ich dann wissen, ob openssl_random_pseudo_bytes() nicht auch Probleme macht? Zumal die "Bytes" ja auch pseudo-zufällig sind. (Handbuch: "Generates a string of pseudo-random bytes") Wovon die Pseudo-Zufälligkeit hier abhängt weiß ich nicht. Bei rand() weiß ich es und ich finde es besser, das zu wissen - weil ich dem dann begegnen kann.

und etwas wie "$salt=dd if=/dev/random bs=32 count=1{:.language-php} oder `$salt=`dd if=/dev/urandom bs=32 count=1 (blockiert nicht, ist aber unsicherer, weil er nach dem Ausschöpfen der "Entropiequellen" kurzerhand Pseudozufall ausliefert)" darf ich hier ja nicht mehr schreiben.

In einem richtigen Programm würde ich es aber ohne jede Hemmung machen.