Uebertragung des Passwort-Hashwerts beim Login -- Bewertung?

[Meillo]

Hoi.

In einer Webapplikation werden die Logindaten als Username und MD5-gehashtes Passwort in einer Datenbank gespeichert.

Wenn man sich per Web-GUI einloggt, dann wird das Klartextpasswort per HTTPS und POST uebertragen und anschliessend auf dem Server gehashed um mit dem Wert in der DB verglichen zu werden.

Im Falle eines Logins per SOAP (ebenfalls HTTPS) wird das Passwort aber als MD5-Hash uebertragen der dann auf dem Server unveraendert mit dem Wert in der DB verglichen wird.

Wie ist diese Situation aus dem Sicherheitsblickwinkel zu bewerten?

Es ist das erste Mal, dass ich das so antreffe. Ich kenne sonst nur den Fall, dass man Klartextpasswoerter base64-kodiert ablegt, damit man sie nicht auf den ersten Blick lesen kann. Das finde ich ganz angenehm, ist aber im Bezug auf die Sicherheit nicht anders als wenn das Klartextpasswort direkt da stehen wuerde.

[TRex]

Mir fehlt ein wenig Salz in der Beschreibung:

https://www.owasp.org/index.php/Passwor ... cific_salt

Darüber hinaus würde ich auch kein MD5 nehmen. Ist die DB mal geleakt, kann sich jeder mit verhältnismäßig wenig Aufwand die Passwörter cracken. Alternativen stehen auch im obigen Link.

[Meillo]

Danke fuer deine Antwort. Ich haette allerdings klarer fragen muessen; mir geht es nur um den einen Aspekt, dass neben dem Login per Klartextpasswort auch ein Login per Passwort-Hashwert moeglich ist. Schwaecht das die Sicherheit und wenn ja wie schlimm und in welcher Weise?

[MSfree]

.... Schwaecht das die Sicherheit und wenn ja wie schlimm und in welcher Weise?

Eigentlich ist beides nicht gut. Die Übertragung des Klartextpaßwortes könnte man im Browser mit entsprechendem Javaskript genauso abfangen wie die Übertragung des Hashes und zwar noch bevor die Verschlüsselung durch SSL greift. Ist der Browser durch Malware verseucht, ist sowieso Hopfen und Malz verloren.

Nutzt man kein SSL, ist es für einen Angreifer egal, ob er bei der Netzwerkübertragung den Hashwert abfängt oder das Paßwort. Denn mit beiden könnte er sich dann beim Webservice anmelden.

Ich denke, es ist Sicherheitstechnisch egal.

[TRex]

Der Login mit hash ist insofern bedenklich, dass es dem entspricht, was jeder mit Zugriff auf die DB hat. Ein salt würde das unmöglich machen (außer du hängst den in den client, was ziemlich blöd wär).

[Liffi]

Das Passwort muss übertragen werden, damit es sicher ist. TRex hat schon geschrieben warum. Ein salt ist einfach Pflicht und sollte dem Benutzer nicht bekannt sein, sondern einfach in der Datenbank liegen. Ohne zufälliges salt sind schon sehr lange Passwörter nötig...

[eggy]

@Liffi:

Salt hat im Normalfall mit der Länge erstmal nichts zu tun. Das ist nur dazu da um die Abbildung der Hashfunktion "zufälliger" zu machen. Bei den meisten Hashfunktionen ist die Ausgabelänge auch nicht von der Eingabelänge abhängig.

Die meisten Verfahren hashen die Passwörter und legen den Hash ab. Hast Du die selbe Hashfunktion kommen bei gleicher Eingabe die selben Ausgaben raus. In der Datenbank landet also statt "Mein tolles Passwort" z.B. der Hash "A9ED".

Du kannst Dir ein Wörterbuch vorberechnen, in dem steht "A9ED hatte das Passwort 'Mein tolles Passwort', BSA7 hatte 'Debian ist super', ...', diese Wörterbücher nennt man Rainbowtables. Geht jetzt irgendwo ne Datenbank mit Usernamen/Email/Passworthashes verloren, kann der Finder sie einfach gegen seine RT werfen und bekommt zu vielen/allen Hashes die original Passwörter geliefert. Und da viele Leute immernoch überall den selben Usernamen/Email verwenden und sich auch mit dem selben Passwort anmelden ist das dann ziemlich doof.

Setzt man jedoch ein Salt ein, verändert man die Ausgabe der Hashfunktion. Du hast zwar immernoch bei gleicher Eingabe das selbe Ausgabeergebnis, auch bleibt die Länge gleich, allerdings ist das Ergebnis nicht mehr global gleich. Mit Salt "XYZ" wird aus "Mein tolles Passwort" dann z.B. "5ILQ" und aus "Debian ist super" "ABC2". Mit Salt "ZYX" kämen dann aber z.B. "12MS" und "S7SX" raus. Du müsstest also pro möglichem Salt eine eigene Rainbowtable haben. Somit ist das "verlieren" von Passwortdatenbanken etwas weniger doof. Denn findet jemand bei $onlineshop die gesaltzte Datenbank, muss er bruteforcen* (kostet Zeit) bis er das zugehörige PW gefunden hat, hätte er ne RT hätte er nur kurz nachsehn müssen.

*: oder sich ne eigene RT vorberechnen, dazu braucht er dann aber das Salt. Manche Entwickler sind so freundlich es direkt mit in der DB abzulegen (was in Hinblick auf SQL-dumps ne blöde Idee ist), oder es anderweitig dem Zugriff des Angreifers auszusetzen. Kostet aber auch Zeit. Zeit, in der $Shopbetreiber den Einbruch erkannt haben, schonmal seine restlichen Passwörter ändern und Kunden warnen könnte *träum*.

[Liffi]

@Liffi:

Salt hat im Normalfall mit der Länge erstmal nichts zu tun. Das ist nur dazu da um die Abbildung der Hashfunktion "zufälliger" zu machen. Bei den meisten Hashfunktionen ist die Ausgabelänge auch nicht von der Eingabelänge abhängig.

Du hast völlig recht, ich glaube, es war noch zu früh für mich . Vermutlich habe ich mich auch sehr unklar ausgedrückt. Wenn ich sehr lange Passwörter habe, ist die Wahrscheinlichkeit, dass zwei Nutzer das gleiche Passwort haben, geringer. Zusätzlich werden die Rainbowtables deutlich größer. Schade, dass ich im müden Zustand nicht in der Lage war, auch genau das zu schreiben.

Und da viele Leute immernoch überall den selben Usernamen/Email verwenden und sich auch mit dem selben Passwort anmelden ist das dann ziemlich doof.

Das ist in der Tat einfach unklug.

*: oder sich ne eigene RT vorberechnen, dazu braucht er dann aber das Salt. Manche Entwickler sind so freundlich es direkt mit in der DB abzulegen (was in Hinblick auf SQL-dumps ne blöde Idee ist), oder es anderweitig dem Zugriff des Angreifers auszusetzen. Kostet aber auch Zeit. Zeit, in der $Shopbetreiber den Einbruch erkannt haben, schonmal seine restlichen Passwörter ändern und Kunden warnen könnte *träum*.

Bei zufälligem salt ist es imho in Ordnung, es direkt in der Datenbank zu speichern. Hauptsache jeder User hat ein eigenes salt.

[Meillo]

Bei zufälligem salt ist es imho in Ordnung, es direkt in der Datenbank zu speichern. Hauptsache jeder User hat ein eigenes salt.

... und das ist nur moeglich wenn man das Passwort uebertraegt, nicht aber wenn man den Hashwert uebertraegt. (Mit dem Hashwert hat man ja auch das Problem, dass die Implementierung auf dem Server fixiert ist und man nicht auf ein sichereres Verfahren umsteigen kann.)

Davon abgesehen scheint es aber egal zu sein, ob man das Klartextpasswort oder den (saltless) Hash oder beides abfangen kann. Kann man das so sagen?

Das eigentliche Problem hier ist also nicht die Sicherheitsgefaehrdung durch das Abfangen der Daten (weil das bei Passwoertern immer die gleiche Gefahr ist), sondern die Fixierung auf genau diese Backend-Implementierung ... die man aus Sicherheitsgruenden aber austauschen sollte.

[Liffi]

Bei zufälligem salt ist es imho in Ordnung, es direkt in der Datenbank zu speichern. Hauptsache jeder User hat ein eigenes salt.

... und das ist nur moeglich wenn man das Passwort uebertraegt, nicht aber wenn man den Hashwert uebertraegt. (Mit dem Hashwert hat man ja auch das Problem, dass die Implementierung auf dem Server fixiert ist und man nicht auf ein sichereres Verfahren umsteigen kann.)

Man kann natürlich auch ein eigenes salt zu dem übertragenen Hashwert speichern. Es ist halt nur nicht sicherer als wenn ein Passwort käme.
EDIT:: schlechte Hashing Verfahren können hier sogar für eine Verschlechterung der Situation sorgen.

Davon abgesehen scheint es aber egal zu sein, ob man das Klartextpasswort oder den (saltless) Hash oder beides abfangen kann. Kann man das so sagen?

Ja, aus Sicht des Servers kommt ja das gleiche (eine Zeichenkette). Wenn man das abfängt, kann man sich einloggen.

Das eigentliche Problem hier ist also nicht die Sicherheitsgefaehrdung durch das Abfangen der Daten (weil das bei Passwoertern immer die gleiche Gefahr ist), sondern die Fixierung auf genau diese Backend-Implementierung ... die man aus Sicherheitsgruenden aber austauschen sollte.

Meinst du damit die spannende MD5 Geschichte? Wenn ja: Dann ja, die MUSS man austauschen.

[Meillo]

Das eigentliche Problem hier ist also nicht die Sicherheitsgefaehrdung durch das Abfangen der Daten (weil das bei Passwoertern immer die gleiche Gefahr ist), sondern die Fixierung auf genau diese Backend-Implementierung ... die man aus Sicherheitsgruenden aber austauschen sollte.

Meinst du damit die spannende MD5 Geschichte? Wenn ja: Dann ja, die MUSS man austauschen.

Aber das groessere Problem (weil strukuturell) ist doch nicht MD5 sondern die serverseitige Saltlosigkeit.

MD5 ist ``bloss'' in der Form schlecht, dass man es schneller Bruteforcen kann als bessere Hash-Algorithmen.

Beide Aspekte verbessern die Situation gegen Angriffe, bei denen Zugriff auf die Usertabelle in der Datenbank besteht. Bei anderen Angriffen ist die Situation unveraendert. Richtig?

[eggy]

Wenn ich sehr lange Passwörter habe, ist die Wahrscheinlichkeit, dass zwei Nutzer das gleiche Passwort haben, geringer.

Nee, das hängt ganz und gar nur von der Hashfunktion hab. Ich könnte ne (zugegebenermassen recht sinnfreie) Hashfunktion bauen die alles was mit "A" anfängt auf "1" abbildet und alles andere auf "0", dabei spielt die Länge der Passwörter keine Rolle.

Zusätzlich werden die Rainbowtables deutlich größer.

Nein, die größe der Rainbowtables hängt ebenfalls nur von der Hashfunktion ab. Im oberen Fall reichen 2 Einträge. Du willst ja nur irgendein Passwort finden, das mit der Hashfunktion den Wert in der Datenbank erzeugt.
Dass ursprünglich "ABC" und "ADASZXZ" auf "1" abgebildet haben ist egal, der Einbrecher wird sich dann halt statt mit dem "richtigen" Passwort (ABC) mit dem "falschen" Passwort (ADASZXZ) einloggen. Im Ergebnis spielts keine Rolle. Denn das "Passwort" wird gehasht, und der Hash mit dem Wert in der DB verglichen und das passt halt in beiden Fällen.

Bei zufälligem Salt ist es imho in Ordnung, es direkt in der Datenbank zu speichern. Hauptsache jeder User hat ein eigenes salt.

Noe, im Idealfall legst Du das dahin, wo der Einbrecher nicht bzw nicht so einfach drankommt. Die meisten "ups die Datenbank ist abhanden gekommen"-Fälle entstehen wohl aufgrund von SQL-Injektions oder falsch konfiguriertem DB-Server. Wenn es dann ein Salt gibt, das "woanders" liegt, ist man schon nen ganzes Stück besser dran.

[Meillo]

Bei zufälligem Salt ist es imho in Ordnung, es direkt in der Datenbank zu speichern. Hauptsache jeder User hat ein eigenes salt.

Noe, im Idealfall legst Du das dahin, wo der Einbrecher nicht bzw nicht so einfach drankommt. Die meisten "ups die Datenbank ist abhanden gekommen"-Fälle entstehen wohl aufgrund von SQL-Injektions oder falsch konfiguriertem DB-Server. Wenn es dann ein Salt gibt, das "woanders" liegt, ist man schon nen ganzes Stück besser dran.

Die PHP-Funktion password_hash() z.B. generiert einen Hashwert, der das Salt mitenthaelt (neben dem verwendeten Hash-Algorithmus und so) und den solle man auch so in der DB speichern. Das widerspricht doch deiner Idee.

Darum wird hier vorgeschlagen, zusaetzlich ein Pepper zu verwenden (beliebiger String, den man mit dem Passwort konkateniert) und diesen einfach im Code abzulegen. (Dann brauchen Angreifer schon Datenbank- und Dateisystem-Zugriff.) Die Pepper-Variante erscheint mir einfacher umsetzbar als das Salt aus der DB rauszuhalten.

[Liffi]

Zusätzlich werden die Rainbowtables deutlich größer.

Nein, die größe der Rainbowtables hängt ebenfalls nur von der Hashfunktion ab.

Dem würde ich widersprechen. Ohne salt und Passwörtern, die nur 4 Zeichen lang sind (und dies dem Angreifer bekannt ist), ist der Rainbowtable gar nicht so groß.

[Liffi]

MD5 ist ``bloss'' in der Form schlecht, dass man es schneller Bruteforcen kann als bessere Hash-Algorithmen.

Und es schon fertige Rainbowtables gibt .

Beide Aspekte verbessern die Situation gegen Angriffe, bei denen Zugriff auf die Usertabelle in der Datenbank besteht. Bei anderen Angriffen ist die Situation unveraendert. Richtig?

Ja. Andere Angriff wie Man-in-the-middle betreffen dich weiterhin. Hier kann man durch Zertifikatpinning und gutes SSL Abhilfe schaffen.

[spiralnebelverdreher]

Hoi.

In einer Webapplikation werden die Logindaten als Username und MD5-gehashtes Passwort in einer Datenbank gespeichert.

Wie ist diese Situation aus dem Sicherheitsblickwinkel zu bewerten?

Passt vielleicht nicht ganz zum Kontext deiner Web-Applikation, aber Angriffe mittels gehashter Passworte waren in der Vergangenheit (im Kontext Windows und Windows Adminkonten) schon erfolgreich: https://www.heise.de/security/meldung/B ... 29862.html