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

[Bbommel]

Huch. Von diesem ganzen neuen Kram muss einem aber auch mal einer was sagen - vielen Dank!

Leider hilft mir das insofern nicht weiter, weil es auch den gleichen MD5-Hash liefert wie die Indy-Funktion (und im übrigen auch ein Online-MD5-Tool) - also wohl den richtigen Hash.

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.

[Sir Rufo]

So ein Hash wird immer von einer Handvoll Bytes errechnet. Wenn du da einen string reingibst, dann wird der in eine Bytefolge zerlegt und davon der Hash ermittelt.

Du könntest also versuchen über TEncoding.GetBytes die Bytefolge für den string mit ANSI-Encoding zu holen und davon den Hash zu errechnen.

[himitsu]

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.

Bei MD5/SHA1 bin ich zum Schluß dazu übergegangen die API der crypt32.dll zu kapseln/nutzen.

[Bbommel]

Hier die Auflösung, vor allem, falls später noch mal jemand drüber stolpert. Das Verhalten der alten fhash-Unit kann man nachstellen, indem man an die neue Funktion aus der system.hash nicht direkt den String übergibt, sondern ihn sozusagen als Byte-Folge mitgibt. Hier ein Beispielprogramm, in welchem der Aufruf der "alten" FHash-Funktion und der bei Delphi jetzt mitgelieferten das selbe Ergebnis liefern:

Delphi-Quellcode:

uses
  System.SysUtils,
  FHash_single,
  System.Hash;

var md5: ThxMD5;
    md5system: THashMD5;
    md5_Fhash: string;
    md5_system: string;
    inStr: String;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
    inStr:=ParamStr(1);
    md5.Init;
    md5.Update(inStr);
    md5.Final;
    md5_Fhash:=md5.asHexString;

    md5system.Reset;
    md5system.Update(inStr[1],Length(inStr)*2);
    md5_system:=md5system.HashAsString;

    writeln('md5 Fhash_single: '+md5_Fhash);
    writeln('md5 System      : '+md5_system);
    writeln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Während die Funktion aus Fhash (hier: fhash_single) immer mit zwei Bytes pro Buchstabe arbeitet, so scheint es mir bei dem richtigen Hash so zu sein, dass zumindest die abschließenden 0-Bytes abgeschnitten werden. Wenn man nun also die neue Funktion zwingt, auch immer zwei Bytes zu nehmen, dann funktioniert es.

Danke für eure Anregungen!

Bis denn
Bommel

[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.

In deinem Fall, also als Unicode (UTF-16) und dann hashen, egal mit welcher Funktion, und alles kann so bleiben
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 von Bbommel:

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 von himitsu:

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.