Hallo,

In der Praxis würde ich das ganz anders aufbauen - aber hier gehts um eine einfache Anleitung die entsprechende Grundlagen vermittelt und keine "do it perfectly"-Lösung.

Ich habe in https://forum.selfhtml.org/?t=215336&m=1474577 versucht zu argumentieren, warum das letztlich eine schlechte Idee ist. Warum fangen wir nicht mal damit an, Anfängern zu beschreiben, wie wir es in der Praxis machen würden.

Natürlich muss man Vereinfachungen vornehmen, Nebenschauplätze ignorieren und den Code wiederverwendbar halten, klar. Aber vor allem aus didaktischen Gründen. Zum Beispiel finde ich PDO und Prepared Statements nicht komplexer als objektorientiertes mysqli mit sprintf-/real_escape_string-Orgien. Ich halte es letztlich sogar für einfacher, weil sich das Problem MySQL-Escaping damit in Luft auflöst. Man muss Low-Level-Operationen wie sprintf und real_escape_string nicht kennen und kann Escaping nicht vergessen.

Diese Funktion ist kryptologisch zwar nicht ausreichend sicher, da der Salt-Wert aber ohnehin einen öffentlichen Teil des abgeleiteten Schlüssels darstellt, können wir diesen Umstand vernachlässigen. Zu seinem späteren Zeitpunkt kann die Funktion recht einfach durch password_hash() ersetzt werden, welche die auch die Erzeugung des Salt-Wertes selbst durchführen kann.

Don’t make me think! Bei HTML, CSS und JavaScript predigen wir Progressive Enhancement, warum nicht auch bei PHP. Best Practice wäre, direkt password_hash und password_verify zu nutzen und ggf. password_compat einzubinden. Der kryptografische Hintergrund ist für den Anwender ohnehin unverständlich. Es reicht zu sagen: Dies ist der vorgesehene, sichere Weg und für ältere PHP-Versionen bauen wir die Funktion so gut es geht nach. Damit spart man sich obigen Krypto-Exkurs und kann sich auf die wichtigen Dinge beschränken, die beim Anwender hängen bleiben sollen. Die Nachricht sollte sein: Nutze gehashte, gesalzene Passwörter, mach es nicht selbst, sondern verwende Standard-PHP-Tools und vorgegebene sichere Algorithmen.

Generell sollten wir Artikel für die Zukunft schreiben, die die heutigen Best Practices dokumentieren und eine gewisse Halbwertszeit haben. Fallbacks für alte PHP-Versionen kann man einbauen. Sie sind aber nur für die technische Funktionsfähigkeit nötig. Die darin verwendeten Techniken braucht der Anwender nicht zu verstehen geschweige denn sich zu merken.

Grüße,
Mathias