While reading this question, it got me to thinking.

Let's say an attacker has some way to make all of their login attempts appear legitimate - enough IP addresses to never reuse them, different valid browser UA strings on each request matching the spread of browsers usually seen, what have you.

Would a strong hashing function that guarantees things like memory or time complexity (for instance, Argon2) not aid a DDoS on a service by way of amplification?

I'm imagining a service that doesn't fail fast on non-existant usernames to avoid leaking information about their existence through timing side channels, or that the attackers have a list of all valid usernames already and is only attempting those.

Would something like requiring CAPTCHA for every attempt completely neuter the problem? If not, is there a way of shifting some of the work of validating the password on the user's end without revealing the hash or being vulnerable to the user being able to send whatever they like back, thus flipping the amplification around?


1 Answer 1


Your question is almost a duplicate of the one you referred to. Anyway some possible solutions that come to mind to reduce login DDoS are:

  • (as you stated) Adding a CAPTCHA for every attempt, keeping in mind that most CAPTCHA can also be broken with a certain probability
  • (as you stated) Random usernames (not using the email and not making usernames public)
  • (similarly to what you propose) Making the attack more expensive by first requiring the client to solve an expensive computational challenge which is easy to verify by the server
  • Delegate authentication to a third party authentication provider capable to withstand (or even prevent) DDoS
  • Two-factor authentication (or even two password authentication), where the simpler factor is hashed with a faster algorithm (e.g. SHA2) and is only used to allow verification of the other factor
  • Strong authentication with tokens having high entropy (e.g. QR code scanned by a mobile APP) requiring less expensive hashing (e.g. SHA2, as BCRYPT would give no advantages)

As you also stated, in case of multi-factor authentication the factors less computationally expensive should be verified first and an appropriate delay should be introduced to not leak which factor failed.

  • 1
    How does requiring the client to compute Bcrypt make a difference? The attacker can send the same hard coded hash every time so it doesn't have to perform the computation while the server will still have to compute the bcrypt.
    – nobody
    Commented Aug 30, 2020 at 7:28
  • 1
    @nobody you're right, instead the server could ask the client to solve a complex computational challenge before accessing password verification Commented Aug 30, 2020 at 16:13

Not the answer you're looking for? Browse other questions tagged .