nicht angemeldet
Hallo,
Hallo,
ich verwende ausnahmsweise mal die Unart alles zu Quoten.
Ohne Salt bringt es dir aber nichts, weil man dann das Klartextpasswort überhaupt nicht mehr schützen müsste. Schließlich ineressiert sich der Angreifer nicht mehr für ein Klartextpasswort, wenn jedes Login-System nur einen Hash haben will. Er muss nicht einmal den Hash vom Passwort berechnen, sondern kann den abgefangenen Hash gleich bei anderen Servern testen.
Nochmal: weder ein Hash noch ein gesalteter Hash dienen in irgend einer Form der Sicherheit des Logins.
Ja, ich weiß das und wusste es von Anfang an. Wir reden aneinander vorbei.
Wenn der Angreifer so weit ist, dass er den HTTP-Traffic überwachen kann, ist es völlig wurst, ob er das Klartextpasswort, den Hash oder einen gesalteten Hash mitliest - er kann sich damit einloggen.
Wenn ich ein Wörtebuch habe, für ein 8-stelliges Passwort, dann wäre dieses genauso groß wie ein Wörtebuch für ein 8-steliges Passwort + Salt.
Ja - der einzige Vorteil der Salt-Variante ist, dass die Tabelle mit Salt erst berechnet werden muss, die andere aber potentiell verfügbar ist.
Das setzt die Sicherheit doch nicht herab.
Nein, bei einem einzelnen Passwort verbessert sie die Sicherheit aber nur sehr unwesentlich, darum ist es in diesem Kontext quasi unnütz.
Wenn sie sich sogar, wenn auch nur unwesentlich, verbessert, solltest du nicht von einem Herabsetzen der Sicherheit sprechen.
Doch damit der Hash nicht bei einem anderen Server verwendet werden kann, wo der Benutzer das gleiche Passwort einsetzt.
Jetzt hab ich dich verstanden - das ist richtig, setzt aber voraus, dass dort dasselbe Loginverfahren genutzt wird. Die Wahrscheinlichkeit, dass das dort auch so ist, ist aber kleiner alsdass dort dasselbe Klartext-Passwort akzeptiert wird.
Wenn jeder auf die im Artikel vorgeschlagene Lösung zurückgreift, haben wir aber ein Problem. Außerdem was meinst du konkret mit verschiedenen Loginverfahren. Im normal-Fall wird halt der Benutzername und das Passwort übertragen und das Passwort unter Umständen als Hashwert. Wenn jedes Loginverfahren den Hash anders berechnet bzw. andere Werte mit einfließen lässt, dann haben wir ja unseren server-spezifischen Wert.
Es steht aber da, dass die Passwörter sicher übertragen werden. Daraus könnte man schließen, dass auch das eigene Loginsystem dadurch sicherer wird. Das ist zwar ein Trugschluss, auf den aber nicht aufmerksam gemacht wird.
Wer aus der sicheren übertragung eines Passworts auf die Sicherheit des Login-Systems schließt, hat den Unterschied zwischen Schlüssel und Schloß nicht verstanden.
Man kann aber eine sichere Übertragung so verstehen, dass der Schlüssel nicht abgefangen werden kann. Für mich bedeutet eine sichere Übertragung mehr, als nur einen Hash zu verschicken.
Naja wir scheinen uns ja langsam zu verstehen...
Du wirst mir sicherlich zustimmen, wenn ich behaupte, dass das direkte und bei jedem Loginverfahren gleich angewandtes hashen eines Passwortes weder einen Vorteil für die Sicherheit des Loginsystems hat, noch davor schützt, dass ein Angreifer diesen Hash auch woanders einsetzen kann. Somit bringt das einfache Hashen, wie in dem Artikel gezeigt, keinen Vorteil.
Mir ist bei eurer Unterhaltung eine Idee gekommen.
Würde es ein Vorteil bringen, wenn man ein Bild mit einer Zahl (wie Captcha) an den Client übermittelt. Mit dem Eingabewert (wird nicht übertragen) aus dieser Zahl wird der Hash gesalzen und auf dem Server vergleichen.
So dürfte das Klartext-Passwort geschützt sein, Replayangriffe sollten durch ein immer anderen Salt, welcher nicht Klartext übermittelt wird, ebenfalls unterbunden werden.
Viele Grüße Novi
mfg Pryos
JürgenB
Der Martin