nicht angemeldet
suitJain. Wenn ich Salt + Passwort durch CRC32 jage, dann ist das auf heutigen Rechnern vermutlich innerhalb von Minuten geknackt.
Ich meinte mit "Versauen" dass ich ohne den Algorithmus zu übernehmen den Wert aus dem Datenbankfeld nicht verwenden kann.
Wenn ein System als Loginverfahren einen md5-Hash nutzt, kann ich diesen Hash nicht in einem System verwenden wo ein Salt vorne drangehängt wird oder hinten oder irgendwie anders.
Daher: Wenn man neue Software schreibt (die sich an der Stelle nicht an Schnittstellen halten muss), sollte man MD5 nicht mehr verwenden, sondern lieber gleich die SHA-2-Familie nutzen. Auch bei sowas wie Passwort-Hashes.
Richtig, genau darauf wollte ich eben hinaus - wenn man sich an eine Schnittstelle halten muss, die verlangt dass das Passwort "sicher" in einer bestimmten Form abgelegt wird, kann man eben nicht einfach mal das Hash-Verfahren ändern ohne alle bisherigen Passwörter unbrauchbar zu machen.
Übrigens: Um das Knacken weiter zu erschweren empfiehlt es sich, das Passwort mehrfach durch die Hash-Funktion zu jagen. Das kostet zwar Rechenzeit, die ist aber für das einmalie Prüfen vernachlässigbar, erhöht aber die nötige Zeit für's Durchprobieren. Pseudocode:
Das hatte ich auch schon erwähnt - allerdings in Form von hash(variabler_salt + hash(salt + passwort)) oder hash(salt + variabler_salt + passwort) - das ist allerdings nur Verschleierung die den Zeitaufwand erhöht, sicherer wird es dadurch nicht (sofern der Algorithmus bekannt ist und man nicht auf Security Through Obscurity setzt).