4 ms·

Interesting read: http://ithare.com/client-plus-server-password-hashing-as-a-potential-way-to-improve-security-against-brute-force-attacks-without-overloading-

• pitaj 7y ago
  That is pretty interesting, but doesn't actually offer up a solution that provides server relief, unless I missed something. In every case they still require that HSrv be a slow hash function.
  • 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 ago
      I 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 ago
        You 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 ago
          That's not what the article states, though it's not very explicit about why you shouldn't do what you suggest.