Unnamed-Projekt > BigInt, MD5, RipeMD320, SHA, Streams usw.

[himitsu]

Das ist aber kein Fehlverhalten der Hashfunktion.

Ich selber wandle Strings inzwischen grundsätzlich immer nach UTF-8 und hashe diesen String dann, somit ist überall das Ergebnis gleich.
Ob man nun ANSI (Eine der vielen CodePages), UTF-8 oder Unicode (UTF-16) hasht, vom Ergebnis muß das andere Werte liefern, sonst ist die Hashfunktion ja kaputt, wenn sie bei unterschiedlichen Byte-Folgen gleiche Ergebnisse liefert. :stupid:

In deinem Fall, also als Unicode (UTF-16) und dann hashen, egal mit welcher Funktion, und alles kann so bleiben :angle:
oder ein anderer "Daten"-Format und dann ist es auch egal welche Hashfunktion du nutzt.

[Bbommel]

Jo, ich hatte in meinem ersten Post "richtig" und "falsch" bewusst noch in Anführungszeichen gesetzt, weil mir schon klar war, dass es nicht wirklich richtig oder falsch ist, sondern darum geht, wie welche Bytes umgewandelt bzw. interpretiert werden. Das mit den Anführungszeichen war mir nachher nur zu lästig. ;)

Ich kam darauf, das eine Ergebnis als "richtig" zu bezeichnen, weil halt die Funktion von Indy, System.hash und PHP (bei einem Online-Tool ausprobiert) dieses Ergebnis lieferte ohne, dass man bewusst irgendwelche Umwandlungen einstellen musste. Am Anfang hatte ich auch einfach nur den Buchstaben "a" als Eingabe für die Funktionen genommen.

Nun habe ich ja für meine existierenden Daten eine Lösung gefunden und für die Zukunft finde ich das Umwandeln in UTF8 eine gute Idee - dann sollte es plattform- und sprachübergreifend ja den gleichen Hash geben.

[himitsu]

PHP und z.B. FreePascal/Lazarus arbeiten an den meisten Stellen mit UTF-8 und müssen bei Systemaufrufen konvertieren. Delphi seit 2009 vorallem mit UTF-16, womit bei WinAPIs oft weiterhin ein PChar-Cast reicht.
Nja, und ich, unerfahren, wie ich war, hatte damals, bei der 2009-Anpassung, die ANSI-Versionen so gelassen, wie sie waren, damit sie gleiche Ergebnisse liefern,
aber die WideString-Versionen als Unicode gehasht, so wie sie rein kommen.

[BUG]

Zitat:

Zitat von Bbommel (Beitrag 1330795)

Wahrscheinlich ist es am besten, einmal in den sauren Apfel zu beißen und die Kunden, die das nutzen, einmal zu bitten, ihre Passwörter neu zu vergeben. Ist ja eigentlich quatsch, aus Kompatibilitätsgründen eine Funktion mitzuschleppen, die ein eigentlich falsches Ergebnis liefern soll.

Dann hier der obligatorische Hinweis: Reine Hashingfunktionen sind zum Schutz von Passworten nicht zu gebrauchen!

Besser sind Schlüsselableitungsfunktionen wie: PBKDF2, bcrypt oder scrypt.
Bei den ersten Beiden kannst du durch das Erhöhen der Rundenanzahl auch nachträglich die Schwierigkeit erhöhen, ohne den Klartext zu kennen. Scrypt ist wegen dem hohem Speicherverbrauch schlecht in Hardware zu implementieren (was es womöglich sicherer macht).

Zitat:

Zitat von himitsu (Beitrag 1330798)

Im Notfall dem gespeicherten Hash ein Prefix/Kennung mitgeben, womit gehasht wurde, da kannst du dann mehrere Verfahren parallel laufen lassen und auch "alte" Hashs unterstützen.

Damit könnte man womöglich auch im Betrieb das Verfahren wechseln. Beim erfolgreichen Anmelden ist der Klartext ja bekannt.