4 ms·
My take away was that the server relief comes from reducing the ability of clients to trigger disproportionate amounts of server resource consumption.
by jaytaylor 7y ago
My take away was that the server relief comes from reducing the ability of clients to trigger disproportionate amounts of server resource consumption.
- nneonneo 7y agoI don’t see how that follows. If HSrv is expensive or slow, a malicious client could just submit nonsense hashes that only look like they might have come from HCli - the server shouldn’t be able to tell the difference. Requiring client-side JavaScript for your login system seems fraught. I would much rather have an approach that does server side hashing exclusively, but gates it behind some kind of DDoS protection or rate-limiting.
- pnako 7y agoYou do the slow (bcrypt, argon2 or whatever) hash in the browser, and then the server can do the hyper-fast hash (SHA256). You can still flood the server, but you're flooding it with things that take microseconds to compute, instead of 50ms.
- tgb 7y agoThat's not what the article states, though it's not very explicit about why you shouldn't do what you suggest.