Kostenloses Bildungsangebot

[molily]

Hallo,

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

Dein Algorithmus hatte verschiedene ernstzunehmende technische Schwächen. Diese wurden ganz sachlich aufgezeigt. Nicht mehr, nicht weniger.

Niemand hier hat hinreichend Ahnung von Kryptographie, um einen eigenen Hashalgorithmus zu implementieren, der in punkto Sicherheit an bewährte Verfahren heranreicht. Nicht du, nicht ich. Daher meine Aussage: Wenn man keine Ahnung von Krypto hat, sollte man die Finger davon lassen.

Das ist technische Professionalität. Wenn ein Kunde anruft und nach Krypto fragt, verweise ich ihn weiter an jemanden, der sich damit auskennt – und seien es meine Kollegen, die IT-Sicherheit studiert haben. Natürlich könnte ich etwas basteln mit meinem zusammengegoogelten StackOverflow- und Heise-Halbwissen, aber das wäre grob fahrlässig.

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.

Hör endlich auf mit diesen haltlosen Unterstellungen. Ich habe schon in meinem ersten Posting auf password_hash() hingewiesen. Das ist eine einfach verwendbare Funktion, die bcrypt verwendet und automatisch einen sicheren Salt erzeugt. Diese zu verwenden ist sicher, den mir bekannten Fakten nach zu urteilen. Für ältere PHPs gibt es einen »Polyfill«, wie wir Frontend-Entwickler sagen würden. Gute Alternativen sind wie gesagt scrypt und PBKDF2.

Dass es die betreffende Seite des Handbuchs noch nicht in deutscher Übersetzung gibt, kannst du mir nicht vorwerfen.

Was du mit deinem verlinkten Posting sagen möchtest, weiß ich nicht. Du bist der einzige, der hash() ins Spiel gebracht hat; ich habe nie davon geredet.

string password_hash ( string $password , integer $algo [, array $options ] )

Fein, den Algorithmus darf man wieder selbst angeben

Der Standardalgorithmus ist bereits eine gute Wahl.

als options['salt'] darf man dann den hash wieder selbst übermitteln

Man muss es nicht. Man sollte es auch nicht. Steht ganz groß im Handbuch.

das läuft also auf das selbe hinaus wie hash_pbkdf2()

Nein, das ist Quatsch. Bei password_hash() muss man den Salt nicht selbst berechnen.

und ist eine Blackbox, weil wieder keiner weiß, was das Ding treibt.

Zum letzten Mal, bcrypt/Blowfish ist keine Blackbox, sondern ein öffentlich spezifizierter und hundertfach implementierter Algorithmus. Blowfish ist seit 1994 bekannt.

PHP ist Open Source, du kannst den C-Quellcode von password_hash lesen. Die Funktion verwendet intern crypt mit Blowfish. Die PHP-Bibliothek password_compat macht dasselbe.

Die crypt-Implementierung ruft php_crypt_blowfish_rn auf, das ist die C-Implementierung von Blowfish.

Was $options['cost'] bewirkt erschliest sich aus der Dokumenattion auch nach dem Folgen von einem halben Dutzend Links nicht.

Es ist ein Parameter für bcrypt. 2^cost ist die Anzahl der Wiederholungen. Diese Seite habe ich bereits verlinkt.

An diesem Parameter braucht man nichts verändern. Sollte man nichts verändern, wenn man nicht weiß, was man tut.

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.

Das ist nachweislich falsch. Es wird nicht richtiger, wenn du es immer wieder behauptest.

bcrypt und Blowfish sind nicht PHP-spezifisch, sondern in vielen Sprachen implementiert. Viele Interpreter von dynamischen Sprachen sind in C implementiert, sie können also auf vorhandenen C-Implementierungen aufbauen.

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.

Falls du es nicht glaubst, schau im PHP-Quellcode nach:

https://github.com/php/php-src/blob/php-5.5.4/ext/standard/password.c#L127-L153
https://github.com/php/php-src/blob/php-5.5.4/win32/winutil.c#L80-L126

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")

Die meisten softwarebasierten Zufallsgeneratoren – so ziemlich alle, über die wir hier gesprochen haben – erzeugen nur Pseudo-Zufallszahlen. openssl_random_pseudo_bytes() ist die einzige Funktion, die dies in ihrem Namen zugibt. Quanten-Zufallsgeneratoren sind vielleicht weniger »pseudo«.

Wovon die Pseudo-Zufälligkeit hier abhängt weiß ich nicht.

Dann informiere dich halt. Über /dev/random gibt es einen Haufen an Literatur, und der Quelltext von Linux ist bekanntlich ebenfalls Open Source.

Bei rand() weiß ich es und ich finde es besser, das zu wissen

Das ändert nichts daran, dass die meisten Entropiequellen angreifbar sind.

Mathias