Verschlüsselte passwörter versenden, warum?
-
guten tag
ich wollte mal wissen, was e denn bringt, wenn ein password an einen server verschlüsselt gesendet wird. angenommen ich benutze einen packet sniffer und sehe das verschlüsselte passwort, sagen wir mal einen MD5 hash. dann könnte ich doch eine application schreiben die das bereits verschlüsselte password an den server sendet und dann sollte ich ja authorisiert werden.
wo genau ist hier der sinn bei verschlüsselten passwörtern, egal ob MD5, htaccess (wahrscheinlich blowfish), etc. wenn man ja den verschlüsselten content des passworts direkt an den server senden könnte? gibt es hier eine vertieftere matherie die mir noch nicht ganz klar ist?
-
-
Hallo,
die Idee ist, dass der Schaden begrenzt wird, wenn das PW gesnifft wurde. Denn man kann nicht (oder schwer) vom Hash auf das Original schließen.
Wenn du den PW Hash von mir rausfindest und ich benutze das PW gerne auch für andere Zugänge, dann ist "nur" dieser eine Zugang kompromitiert, nicht aber alle andere, wie es bei einem reversiblem Hash der Fall wäre.
-
Ich glaub du verwechselst da was. Die Passwoerter werden nicht verschluesselt um sie zu uebermitteln, sie werden kodiert um sie zu speichern. Man speichert keine klartext Passwoerter, sendern z.B. deren MD5 Hash.
Das hat den Sinn, dass wenn jemand den Server hack, er nur die Hashes sehen kann. Diese Hashwerte kann er aber weder in Klartext umwandeln, noch kann er die Hashwerte als Passwoerter verwenden.
Ausserdem wird meist noch ein Salted-Hash errechnet, http://de.wikipedia.org/wiki/Salted_Hash, so das man nicht mal mehr durch durchprobieren der ueblichen Passworter den Hash in Klartext umwandln kann.
-
Darüber hinaus ist normalerweise die gesamte Verbindung zwischen Client und Server verschlüsselt, d.h. du weißt gar nicht wo das Passwort ist.
-
Oliver schrieb:
hm... und was bringt das bei clientseitiger Codierung, wenn ich den Zufallswert ebenfalls mit übersenden muss, damit der Server daraus das Passwort errechnen kann?
Bei serverbasierter Codierung ist die Sache klar, da auch zwei gleiche Passwörter so einen unterschiedlichen Hashwert bekommen, aber clientseitig ist es wohl genauso anfällig und kein Ersatz für SSL, oder seh ich da was nicht richtig?DEvent schrieb:
Das hat den Sinn, dass wenn jemand den Server hack, er nur die Hashes sehen kann. Diese Hashwerte kann er aber weder in Klartext umwandeln, noch kann er die Hashwerte als Passwoerter verwenden.
auch da seh ich zuviel Vertrauen in die Hash-Funktion... ist er erstmal im Server, nützt dem User/Admin der Hashwert garnichts... Einfach alle Hashwerte ersetzen oder aus Frust alle Tabellen löschen, da bringt der beste Hashwert nichts.
Der Hashwert ist nur dann Sinnvoll, wenn irgendjemand an den Hashwert kommt, bspw. wenn der Tabelleninhalt fälschlicherweise auf der Seite ausgegeben wird. Aber hat der Angreifer erstmal Zugang zum Server, ist ihm ein Hashwert egal (imho)
-
zwutz schrieb:
Der Hashwert ist nur dann Sinnvoll, wenn irgendjemand an den Hashwert kommt, bspw. wenn der Tabelleninhalt fälschlicherweise auf der Seite ausgegeben wird. Aber hat der Angreifer erstmal Zugang zum Server, ist ihm ein Hashwert egal (imho)
Auf DIESEM System ja. Aber der angreifer kann dein Online Bankkonto nicht leerräumen, weil er das Klartext password nicht kennt.
-
tfa schrieb:
Darüber hinaus ist normalerweise die gesamte Verbindung zwischen Client und Server verschlüsselt, d.h. du weißt gar nicht wo das Passwort ist.
du erzählst unfug. es hängt ja wohl vom jeweiligen dienst oder protokoll ab, ob verschlüsselt wird oder nicht. und von einem konkreten protokoll war hier nirgends die rede.
und selbst wenn verschlüsselt wird, warum sollte man nicht wissen können, wo das passwort steht?
-
// EDIT: war falsch
-
zwutz schrieb:
Oliver schrieb:
hm... und was bringt das bei clientseitiger Codierung, wenn ich den Zufallswert ebenfalls mit übersenden muss, damit der Server daraus das Passwort errechnen kann?
Bei serverbasierter Codierung ist die Sache klar, da auch zwei gleiche Passwörter so einen unterschiedlichen Hashwert bekommen, aber clientseitig ist es wohl genauso anfällig und kein Ersatz für SSL, oder seh ich da was nicht richtig?Der Server schickt dir einen zufällig generierten Salt den der Client ans Passwort hängt und dann den Hash zurückschickt. Der Client darf den Salt natürlich nicht selber generieren. Das wäre in der Tat sinnlos.
