Hallo Welt
Beim Implementieren eines kleinen REST-Services bin ich mal wieder etwas ins Grübeln gekommen.
Warum ist Client-Side Hashing nicht Standard?
Bei Websites ist der heutige Prozess des Logins ja so:
Bei Client-Side Hashing könnte man es - als Beispiel - so gestalten:
Das Internet schlägt fast immer in die gleiche Kerbe: "Es ist nur wenig bis gar nicht sicherer als pures HTTPS"
https://stackoverflow.com/questions/3715920/is-it-worth-hashing-passwords-on-the-client-sidehttps://security.stackexchange.com/...client-side-hashing-of-a-password-so-uncommonhttps://news.ycombinator.com/item?id=18350244
Die vorgeschlagenen Alternativen:
Gegenargument "Weniger Entropie": Trifft nur bei Passwörtern < 32 Bytes auf. Ich denke, das ist vernachlässigbar.
2 Fragen / Diskussionspunkte dazu:
1) Warum wird das nicht von Entwicklern umgesetzt? Klar, es ist ein bisschen mehr Arbeit, aber jetzt auch nicht die Welt.
2) Warum wird es nicht von den "Grossen" gepusht? Will man den Passwort-Reuse-Leuten nicht helfen? Oder kann man sich nicht vorstellen, dass ein Server übernommen wird?
Ich freue mich auf jeden Input
Gruss
cwriter
Beim Implementieren eines kleinen REST-Services bin ich mal wieder etwas ins Grübeln gekommen.
Warum ist Client-Side Hashing nicht Standard?
Bei Websites ist der heutige Prozess des Logins ja so:
- Client schickt Nutzername und Passwort über HTTPS an den Server
- Der Server prüft den bereits gespeicherten Hash für diesen Nutzernamen per hash(password + salt) und wenn die Hashes übereinstimmen, gilt das Passwort als korrekt.
- Client (und Nutzer). Immer verwundbar.
- Server (offline - z.B. Datenbankauszug). Durch Hashes und Salts (wenn gut gewählt) kaum ein Problem bei Rainbowtable-Angriffen.
- Server (online - z.B. böser Admin). Verwundbar, da Passwörter im Klartext. Wenn jemand ein Passwort an mehreren Orten verwendet -> Erwischt.
Bei Client-Side Hashing könnte man es - als Beispiel - so gestalten:
- Client schickt Nutzername über HTTPS an den Server
- Der Server schickt den gespeicherten Salt an den Client
- N.B.: Damit die Existenz eines Nutzers nicht geleakt wird, müsste jeder angefragte Nutzer einen eindeutigen, niemals wechselnden Salt bekommen. Idealerweise müssten also Dummy-Nutzer gespeichert werden (die man natürlich überschreiben könnte, wenn man den Salt gleich hält).
- Der Client schickt (Nutzername, Hash(Passwort + Salt)) an den Server
- Der Server prüft den bereits gespeicherten Hash für diesen Nutzernamen direkt mit einem erneuten Hash (gespeichert= Hash(Hash(Password + SaltClient) + SaltServer)) und wenn die Hashes übereinstimmen, gilt das Passwort als korrekt.
- Client (und Nutzer). Immer verwundbar.
- Server (offline - z.B. Datenbankauszug). Durch Hashes und Salts (wenn gut gewählt) kaum ein Problem bei Rainbowtable-Angriffen.
- Server (online - z.B. böser Admin). Kein Problem mehr, da ein böser Admin ohnehin Zugriff auf die Daten des Dienstes hat. Die Daten an anderen Orten sind aber sicher, solange die Hashes sicher sind.
Das Internet schlägt fast immer in die gleiche Kerbe: "Es ist nur wenig bis gar nicht sicherer als pures HTTPS"
https://stackoverflow.com/questions/3715920/is-it-worth-hashing-passwords-on-the-client-sidehttps://security.stackexchange.com/...client-side-hashing-of-a-password-so-uncommonhttps://news.ycombinator.com/item?id=18350244
Die vorgeschlagenen Alternativen:
- Passwortmanager. Wissen wir alle, benutzt fast niemand. Sind schlecht für die Usability
- 2FA: Löst das Problem nicht. Es braucht nur 1 Seite ohne 2FA, die dasselbe Passwort hat, um wieder ein Problem zu sein
- HTTPS: Ist keine Lösung für böse Endpoints.
Gegenargument "Weniger Entropie": Trifft nur bei Passwörtern < 32 Bytes auf. Ich denke, das ist vernachlässigbar.
2 Fragen / Diskussionspunkte dazu:
1) Warum wird das nicht von Entwicklern umgesetzt? Klar, es ist ein bisschen mehr Arbeit, aber jetzt auch nicht die Welt.
2) Warum wird es nicht von den "Grossen" gepusht? Will man den Passwort-Reuse-Leuten nicht helfen? Oder kann man sich nicht vorstellen, dass ein Server übernommen wird?
Ich freue mich auf jeden Input
Gruss
cwriter
Zuletzt bearbeitet: