New answers tagged

1

Your endpoint presumably checks that the username exists in your account database (an inexpensive check) before proceeding with the more expensive key derivation function. Presumably your attacker does not know a large number of usernames to hammer away at your endpoint with. So, you should be able to mitigate this type of attack to some degree by rate-...


5

Yes, that is a valid concern. As for how to mitigate it, you have several (not mutually exclusive) options: One thing that you've already implemented is not doing slow key derivation on every request, but rather having an authentication endpoint that takes a passphrase (or equivalent), applies a slow key-stretching KDF, verifies the correctness of the ...


3

You don't need captcha, you can make the client send a proof of work token along with the username and password. It would go like this: Client GET /account/challenge and receive a nonce Client have to MD5(nonce + random string) until he finds a hash with the first (or last) 4 digits as zeroes Client POST /account/authenticate with nonce, random string, ...


3

Yes, they can potentially be a DoS issue (either for CPU or memory) if you don't have any kind of rate limiting in place. But then if you're not rate-limiting login requests, you have all kinds of other security issues as well. Rate limiting, CAPTCHA, IP blocking, etc can also be used to protect against this. You also need to find an appropriate balance when ...


Top 50 recent answers are included