Flatpress - sichere Passwortfunktion statt MD5 Hash
Ich hatte es es ja genauso in mein meinen Webtools mit Login gern gemacht: neben dem Admin User wurde das Passwort als MD5 Hash in einer Config-Datei hinterlegt.
Die Hashfunktion MD5 ist nach IT Masstäben nicht mehr wirklich sicher - heisst: man kann mit einem zeitlich vertretbaren Aufwand aus dem Hash das (oder ein) Passwort ermitteln, dass auf den Hash matcht. Verzichtet man gar auf Salts, ist der Angreifer mit Rainbow Tables gar in Sekundenbruchteilen am Ziel. Das ist gar nicht gut. Auf MD5 sollte man heutzutage beim Hashing von Passwörtern - egal ob in einer Konfigurationsdatei oder Datenbank-Feld - komplett verzichten.
Ich will es keineswegs verdammen: als reine Hash Funktion zum Bilden von Prüfsummen von nicht-sensiblen Daten, wie Prüfsummen von Download-Dateien, ist es bedenkenlos einsetzbar.
Aber zurück zum Speichern von Passwörtern. PHP bietet seit einiger Zeit von Haus sichere Funktionen an, sichere Passwort-Hashes zu generieren [2] wie auch eine Check-Funktion [3]. Auf dieses Paar habe ich meine Tools umgestellt und kannte das Prozedere der Umstellung bereits.
Da ich hier als “mein” Blogtool Flatpress seit gefühlten Äonen selbst verwende, hab ich mich gern auch an jenem Tool drangesetzt, und dessen md5 Passwort-Hash durch eine sicherere Variante ersetzt - und eine Lösung für den Issue #59 [4] als Pull Request eingereicht.
Das gilt nicht nur für die neu angelegten Passwörter - auch die Migration ist berücksichtigt: bestehende mit md5 Hash gespeicherte Passwörter werden on the fly beim nächsten Login umgeschrieben.
Arvid, danke und merci für den Merge und Erwähnung auf Twitter [1] für die kommende Version 1.2!
I love OpenSource :-)
weiterführende Links:
Samstag, Januar 2, 2021 - 16:12:08
Der Dank gilt dir :) Die Migration ist sehr clever mit Bordmitteln umgesetzt.
Ja, quelloffene Software macht wirklich Spaß :)
Samstag, März 6, 2021 - 17:46:40
Interessante Thematik.
Der Hash, egal wie erzeugt oder sicher, ist unwichtig, wenn das Passwort eines CMS-/Blog-/E-Shop-/Website System in einer der vielen Passwort Listen enthalten oder zu einfach ist.
Man könnte im Text oben ergänzen, dass man zuerst das Augenmerk auf die Sicherheit des verwendeten Passwort richten sollte.
Mittwoch, März 10, 2021 - 22:33:21
Hallo Matthias,
danke für deinen Hinweis!
Das Verhalten bei Hashes ist, dass eine Hashfunktion für einen Text bei jeder Wiederholung immer denselben Hash ermittelt. Es ist also eine (fixe) Prüfsumme. Am bekanntesten sind wohl die Rainbowtables, die viele der einfachen Passworte (und ganze Wörterbücher) gespeichert haben - und so zu einem Hash eines einfachen Passwortes sehr schnell einen möglichen Klartext liefern können. Als Gegenmassnahme gegen Rainbowtables sollte man immer einen Salt bei der Hashfunktion einsetzen.
Und man sollte zum Speichern eines Benutzer-Passwortes am besten gar keine (!) Hash-Funktion benutzen.
Um es nicht falsch zu verstehen: Hashes haben sehrwohl ihre Daseinsberechtigung - aber für einen anderen Zweck.
Passwortfunktionen verhalten sich nochmal anders: sie generieren für ein und deselben Vorgabetext bei jedem Aufruf ein anderes (!) gecryptetes Passwort. Jene gecryptete Ausgabe kann man ebenfalls in der Datenbank speichern. Der Passwort-Vergleich nach einem Login erfolgt mit einer Verify-Funktion (statt mit dem Vergleich derselben Hashmethodik des eingegebenen Passwortes und dem Hash in der Datenbank).
Link: https://www.axel-hahn.de/kiste/werkzeuge/md5
Nach Eingabe eines Textes … unter “Passwort-Hash” ändert sich mit jedem Reload die Ausgabe.
Abschliessend: als Benutzer weiss man nicht, was ein Shop-/ CMS-/ Irgendwas-Betreiber mit den Logindaten nach einer Registrierung im Hintergrund macht. Er könnte das Passwort auch im Klartext speichern - man sieht es ja nicht (autsch!). In einem Opensource-Produkt liesse sich das aber immerhin noch prüfen. Ein sicheres Passwort ist dennoch natürlich immer Pflicht.
Viele Grüsse
Axel