5 ms·

I can attest to this. Credential stuffing was the number 1 reason we decided to add the pwnedpassword validation to our signup flows. We were seeing thousands o

I can attest to this. Credential stuffing was the number 1 reason we decided to add the pwnedpassword validation to our signup flows. We were seeing thousands of IP addresses and hundreds of thousands of requests over a few days. Rate limiting slows it down but doesn’t help all that much. Rate limiting on a specific username will prevent brute forcing but exposes you to DOS. Rate limiting by IP becomes less effective when thousands are involved and most requests end up succeeding. Disclaimer: work for Kogan who is mentioned in TFA.

snowwrestler 8y ago
> Rate limiting by IP becomes less effective when thousands are involved and most requests end up succeeding. What do you mean by "end up succeeding"? Most requests successfully authenticated? On the first try? Second try? Tenth try? Hundredth try? (I'm not trying to doubt the utility of pwnedpassword validation; just hoping you can help me understand the threat you're facing and why IP rate limiting didn't help much. Thanks.)
- URSpider94 8y ago
  I think what he’s saying is that if the attacker has enough IP addresses at their disposal, they can spread out the attack broadly enough that any IP-based rate limit that would stop a bot would also impact human users. Thus most of the bot attempts slip in under the rate limit.
- snowwolf 8y ago
  Perhaps an example will help. Lets say you have IP throttling/rate limiting. And you have it set to an extremely conservative limit - 1 sign in attempt every hour. This is great for the brute force threat - 24 passwords a day can be attempted by 1 IP. Infeasible for any brute forcing. But now lets say the attacker has access to a botnet with 6 million unique IP addresses (not theoretical - see my comment above). Now for each of those 6 million IPs they can try 24 passwords a day - i.e. 144 million attempts a day without ever triggering the throttle. Bear in mind also that they aren't just trying random passwords for an account - they have a compiled/combined breach list of known account/password combinations from other breaches. So they can attempt 144 million known combinations a day. Without hitting any throttles (this is what the parent above means by "end up succeding"). What percentage of your users reuse passwords and have been exposed to at least one breach? I would suggest it's quite a high value. How long do you think it will take a credential stuffing attack to identify those accounts on your site when they can try 100's of millions of combinations a day? This is the threat vector.
  - jsmeaton 8y ago
    Thank you, this covered what I was trying to say.
  - jessaustin 8y ago
    ISTM the next step would be to rate limit for a given account without regard to IP. Sure that's a potential DOS, but we can wait until that's actually a problem before worrying about it.
    - snowwolf 8y ago
      They aren’t trying the same account multiple times. Well they may be conincidentally (if the user uses a unique password per site and has been breached from multiple sites so appears in the breach list multiple times with different passwords) but not that frequently. What they are looking for is the intersection of users who reuse passwords and have been exposed by a breach and those users who have created an account on your site reusing the same password. Which is perhaps not surprisingly a relatively large percentage of your users.
  - snowwrestler 8y ago
    From a wrestler to a wolf: thank you. Very helpful.
C7H8N4O2 8y ago
> Rate limiting on a specific username will prevent brute forcing but exposes you to DOS. Why?
- Sohcahtoa82 8y ago
  You can lock a user out of their account by spamming the server with login attempts.
  - jsmeaton 8y ago
    Yes. In this case the denial of service is against specific customer accounts for the lockout duration, not against the availability of the site.
    - jessaustin 8y ago
      This would be bad, but what's the motivation? What fabulous prizes await the DOSer of some random account on your service?
      - jsmeaton 8y ago
        Locking users out of their accounts isn’t the goal, it’s just an unfortunate side effect.
- bluesroo 8y ago
  Not the OP, but I think he's referring to the potential for an automated service spamming thousands (or more) accounts enough to lock them.

snowwrestler 8y ago

> Rate limiting by IP becomes less effective when thousands are involved and most requests end up succeeding. What do you mean by "end up succeeding"? Most requests successfully authenticated? On the first try? Second try? Tenth try? Hundredth try? (I'm not trying to doubt the utility of pwnedpassword validation; just hoping you can help me understand the threat you're facing and why IP rate limiting didn't help much. Thanks.)

URSpider94 8y ago
I think what he’s saying is that if the attacker has enough IP addresses at their disposal, they can spread out the attack broadly enough that any IP-based rate limit that would stop a bot would also impact human users. Thus most of the bot attempts slip in under the rate limit.
snowwolf 8y ago
Perhaps an example will help. Lets say you have IP throttling/rate limiting. And you have it set to an extremely conservative limit - 1 sign in attempt every hour. This is great for the brute force threat - 24 passwords a day can be attempted by 1 IP. Infeasible for any brute forcing. But now lets say the attacker has access to a botnet with 6 million unique IP addresses (not theoretical - see my comment above). Now for each of those 6 million IPs they can try 24 passwords a day - i.e. 144 million attempts a day without ever triggering the throttle. Bear in mind also that they aren't just trying random passwords for an account - they have a compiled/combined breach list of known account/password combinations from other breaches. So they can attempt 144 million known combinations a day. Without hitting any throttles (this is what the parent above means by "end up succeding"). What percentage of your users reuse passwords and have been exposed to at least one breach? I would suggest it's quite a high value. How long do you think it will take a credential stuffing attack to identify those accounts on your site when they can try 100's of millions of combinations a day? This is the threat vector.
- jsmeaton 8y ago
  Thank you, this covered what I was trying to say.
- jessaustin 8y ago
  ISTM the next step would be to rate limit for a given account without regard to IP. Sure that's a potential DOS, but we can wait until that's actually a problem before worrying about it.
  - snowwolf 8y ago
    They aren’t trying the same account multiple times. Well they may be conincidentally (if the user uses a unique password per site and has been breached from multiple sites so appears in the breach list multiple times with different passwords) but not that frequently. What they are looking for is the intersection of users who reuse passwords and have been exposed by a breach and those users who have created an account on your site reusing the same password. Which is perhaps not surprisingly a relatively large percentage of your users.
- snowwrestler 8y ago
  From a wrestler to a wolf: thank you. Very helpful.

C7H8N4O2 8y ago

> Rate limiting on a specific username will prevent brute forcing but exposes you to DOS. Why?

Sohcahtoa82 8y ago
You can lock a user out of their account by spamming the server with login attempts.
- jsmeaton 8y ago
  Yes. In this case the denial of service is against specific customer accounts for the lockout duration, not against the availability of the site.
  - jessaustin 8y ago
    This would be bad, but what's the motivation? What fabulous prizes await the DOSer of some random account on your service?
    - jsmeaton 8y ago
      Locking users out of their accounts isn’t the goal, it’s just an unfortunate side effect.
bluesroo 8y ago
Not the OP, but I think he's referring to the potential for an automated service spamming thousands (or more) accounts enough to lock them.