Passworts auf dem Server oder auf dem Endgerät hashen?

Status
Für weitere Antworten geschlossen.
KitKat::new() schrieb:
Verhindert z.B., dass der Serverbetreiber oder Angreifer desselben das Passwort abgreifen können und z.B. für andere Dienste missbrauchen können, wo man ggf. ein ähnliches Passwort genutzt hat.
Wenn du dem Serverbetreiber dahingehend nicht vertraust, dann solltest du auch dem von ihm ausgelieferten JS Code nicht vertrauen, der das Passwort angeblich bei dir schon hasht. Das jedesmal zu prüfen ist aber extrem unpraktikabel und macht niemand(tm), von daher hat das keine praktische Relevanz.
Der sinnvolle Weg besteht darin, einen PW Manager und einmalige PWs zu verwenden.

KitKat::new() schrieb:
Vielleicht noch Mal nachdenken bevor man Verallgemeinerungen absendet.
Was er meint ist vllt. nicht genau das was er schrieb, aber es ist mir zumindest völlig klar gewesen was er gemeint hat, von daher ist dein abwertender Ton hier fehl am Platz.
 
  • Gefällt mir
Reaktionen: Funkener
@AW4: Ja, du hast recht, das war ungluecklich formuliert. Ein sicherer Algorithmus ist auch dann sicher, wenn er einsehbar ist.
Damit meine ich eigendlich mehr das der Code offen und nicht vor Manipulation geschuetzt ist wenn er auf dem Client laeuft. Das was ich dann im letzten Absatz konkretisiert habe.

Dazu sei dann auch noch an den TE gerichtet: Baue keine eigenen Authentifizerungsverfahren. Nutze bestehende, als sicher geltende Verfahren.

@KitKat::new(): Dann vielleicht mit einer Einschraenkung: Setze das Wort "alleine" ein ;)
 
  • Gefällt mir
Reaktionen: Funkener
Wenn man ansonsten alles richtig macht, dann ist das hashen auf der Clientseite komplett überflüssig und bringt kein Stück Sicherheit.

Währen dem Transport ist das Klartextpassword durch TLS geschützt. Auf dem Server wird es dann mit einer für Passwörter geeigneten Methode wie PBKDF2, bcrypt, scrypt, ... gehasht. Wenn man jetzt noch clientseitig hasht ändert das nichts, dieser Hash wird dann einfach zum Passwort. Aber solange dieses Passwort halbwegs stark ist bekommt man das sowieso nicht mehr aus dem gespeicherten Hash raus.

Clientseitig Hashen würde ein kleines bißchen was etwas bringen wenn der Client vertrauenswürdig ist, der Server aber nicht. Das würde verhindern das der Server an das Klartextpasswort kommt. Aber diese Konstellation ist eher ungewöhnlich, und z.B. bei Webseiten praktisch ausgeschlossen da der Clientcode vom nicht vertrauenswürdigen Server ausgeliefert wird. Und wenn man tatsächlich dieser ungewöhnlichen Situation hat, ist es eher ein Zeitpunkt zu dem man auf ganz andere Methoden setzt und gar keine Passwörter zum Server überträgt.
 
  • Gefällt mir
Reaktionen: Funkener, owned139 und JP-M
BeBur schrieb:
Wenn du dem Serverbetreiber dahingehend nicht vertraust, dann solltest du auch dem von ihm ausgelieferten JS Code nicht vertrauen
1. Der (evtl. JS) Code wird nicht notwendigerweise vom Serverbetreiber ausgeliefert (z.B. nach Audit duchs Unternehmen an die Mitarbeiter, z.B. GPlay, z.B. separate Infrastruktur)
2. Better safe than sorry
3. Nicht jeder Nutzer trifft hier eine bewusste Entscheidung frei von Zwängen (man siehe mal auf die Situation mit WhatsApp)
4. Wie schon geschrieben, kann der Serverbetreiber angegriffen werden, weshalb überhaupt erst Hashes auf dem Server gemacht werden
5. Der Serverbetreiber kann durch Geheimdienste zu einem Leak gezwungen werden

BeBur schrieb:
der das Passwort angeblich bei dir schon hasht. Das jedesmal zu prüfen ist aber extrem unpraktikabel und macht niemand(tm), von daher hat das keine praktische Relevanz.
Je nach Setup ist ein solches Verifizieren ziemlich einfach, sh. reproducible builds.
Es muss auch nicht von jedem gemacht werden.
Eine Person, die es macht, reicht um die Problematik aufzudecken.

Selbst wenn nichts davon zutrifft: Ein PW ist serverseitig abzufangen ist einfacher als eine Backdoor auszuliefern (z.B. müssen dann u.a. die Frontendentwickler mitspielen).

BeBur schrieb:
Der sinnvolle Weg besteht darin, einen PW Manager und einmalige PWs zu verwenden.
Sinnvoll ist von der Realität auszugehen, in der das nicht jeder nutzt und es sich auch nicht so schnell ändern wird

BeBur schrieb:
aber es ist mir zumindest völlig klar gewesen was er gemeint hat, von daher ist dein abwertender Ton hier fehl am Platz.
😉

owned139 schrieb:
Nein, weil dann der Hash übertragen wird und man im Zweifel nur an den Hash kommen muss, um Zugriff zu erlangen und nicht mehr ans eigentliche Passwort.
Und? Das habe ich in #6 schon beschrieben.
Nur was hat das eine mit dem anderen zu tun?
 
KitKat::new() schrieb:
Je nach Setup ist ein solches Verifizieren ziemlich einfach, sh. reproducible builds.
Was für ein "Build"? Wir sprechen hier von ausgeliefertem JS Code, da wird nichts gebaut. Du musst schon jedes mal im Browser nachschauen, was der Webserver denn diesmal ausgeliefert hat.

KitKat::new() schrieb:
1. Der (evtl. JS) Code wird nicht notwendigerweise vom Serverbetreiber ausgeliefert (z.B. nach Audit duchs Unternehmen an die Mitarbeiter, z.B. GPlay, z.B. separate Infrastruktur)
Bei 1. bis 4. wird halt einfach anderer JS Code ausgeliefert.

KitKat::new() schrieb:
Selbst wenn nichts davon zutrifft: Ein PW ist serverseitig abzufangen ist einfacher als eine Backdoor auszuliefern (z.B. müssen dann u.a. die Frontendentwickler mitspielen).
Ja, das ist korrekt.

Ich wiederhole nochmal, was ich schrieb:
BeBur schrieb:
Wenn du dem Serverbetreiber dahingehend nicht vertraust, dann solltest du auch dem von ihm ausgelieferten JS Code nicht vertrauen, der das Passwort angeblich bei dir schon hasht. Das jedesmal zu prüfen ist aber extrem unpraktikabel und macht niemand(tm), von daher hat das keine praktische Relevanz.
Es hat keine praktische Relevanz aus den genannten Gründen.
 
  • Gefällt mir
Reaktionen: JP-M
BeBur schrieb:
Was für ein "Build"? Wir sprechen hier von ausgeliefertem JS Code, da wird nichts gebaut. Du musst schon jedes mal im Browser nachschauen, was der Webserver denn diesmal ausgeliefert hat.
Du sprichst von ausglieferten JS Code. Nicht ich. Die Welt besteht nicht nur aus JS.
Ausserdem:
1. Der meiste JS Code dürfte auch heute einem Buildprozess durchlaufen, so z.B. der des TE
2. JS wird nicht nur von Webservern und für den Browser ausgeliefert
3. Beschriebenes kann man auch mit selbstgeschriebenen JS Code machen, bzw. ist es damit umso leichter

BeBur schrieb:
Bei 1. bis 4. wird halt einfach anderer JS Code ausgeliefert.
oder auch nicht - 1. würde z.B. wohl nicht durch den Audit gehen, 4. nur weil der Angreifer es ins Backend schafft, heisst es nicht, dass er rechtzeitig zusätzlich ein manipuliertes Frontend ausliefern kann, etc.

5. Kann man ausserdem nicht einfach aussenvorlassen

BeBur schrieb:
Es hat keine praktische Relevanz aus den genannten Gründen.
Definiere praktische Relevanz.
 
KitKat::new() schrieb:
Du sprichst von ausglieferten JS Code. Nicht ich. Die Welt besteht nicht nur aus JS.
Ok. Ich habe von Web und Browser gesprochen, du offenbar nicht. Da bin ich eher raus, wenn du nicht gewillt bist, so ein missverständnis eigenständig aufzulösen, denn so liest sich das für mich.
Bei deinen Stichpunktartigen ausführungen sehe ich sowieso keine Klärungsmöglichkeit.
 
KitKat::new() schrieb:
Verhindert z.B., dass der Serverbetreiber oder Angreifer desselben das Passwort abgreifen können und z.B. für andere Dienste missbrauchen können, wo man ggf. ein ähnliches Passwort genutzt hat.
Da trägt der User dann selbst Schuld daran.
Wenn der Server nur einen vorgehashten Wert bekommt, kannst du auch nicht mehr zuverlässig (serverseitig) prüfen, dass ein neues zu setzendes Passwort irgendwelchen Mindestanforderungen bezüglich Länge, Komplexität und so entspricht. Allerdings ist ein User dann auch doppeldoof, wenn er die clientseitige Prüfung umgeht und ein gehashtes "123" an den Server schickt :)
 
BeBur schrieb:
Ich habe von Web und Browser gesprochen, du offenbar nicht.
Doch, ich auch. Nur habe ich mich nicht auf diese Technologien festgenagelt

BeBur schrieb:
Da bin ich eher raus, wenn du nicht gewillt bist, so ein missverständnis eigenständig aufzulösen
hatte ich doch jetzt getan, eigentlich sogar im vorherigen Post (sh "evtl. JS")

BeBur schrieb:
Bei deinen Stichpunktartigen ausführungen sehe ich sowieso keine Klärungsmöglichkeit.
Warum? verstehst du was nicht?

DarkAngel2401 schrieb:
Da trägt der User dann selbst Schuld daran.
richtig, aber ist ja nicht schlimm
 
Einfach mal so als total losgelöstes Lesematerial:

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Und ansonsten:

1. Nutze SSL / TLS. (Das muss nach DSGVO so oder so gemacht werden bei sensiblen, personenbezogenen Daten / Eingaben)
2. Was im Client passiert, kann jeder lesen oder rekonstruieren, mit mehr oder weniger Aufwand.
3. Was im Server passiert, passiert im Server und für diese Implementierungen gibt es mehr als genug Material darüber, wie man das möglichst sicher bzw. umständlich zu knacken umsetzen kann.
 
  • Gefällt mir
Reaktionen: Funkener und owned139
Ich wollte mich auch nochmal melden. Vielen Dank an alle für die hier geführte Diskussion! Fühle mich nun sicherer bei dem Thema.
JP-M schrieb:
Die Seite habe ich sogar bei meiner eigenen Recherche auch schon gefunden, sehr zu empfehlen! Habe das auch meinen Programmierer bereits gesendet. Er sollte sich das neben zwei anderen Seiten ganz genau durchlesen und wichtige Dinge übernehmen. Das hat er nun getan und ich habe nun ein gutes Gefühl, dass wir nun alles richtig umsetzen.

Verwendet wird nun JWT mit PassportJS und die Passwörter werden auf dem Server mit Argon2 gehasht.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben