4 ms·

Yeah, after 3 failed attempts, just lock the user for 1 second. Brute force still will lead nowhere and real users will hardly notice. I wonder why this didn't

Yeah, after 3 failed attempts, just lock the user for 1 second. Brute force still will lead nowhere and real users will hardly notice. I wonder why this didn't establish in the first place...

jjnoakes 10y ago
Why wait until 3 tries? Why not just require 1 second between all attempts?
- blauditore 10y ago
  Hmm, I guess this makes sense. Not sure what I was thinking...
- viggity 10y ago
  if you're hashing with PBKDF2 and 100k+ iterations, it can take that long anyway.
  - tedunangst 10y ago
    But not in parallel.
    - sleavey 10y ago
      Can hashing iterations be conducted in parallel? Doesn't the next hash need the output of the last, making this a sequential operation?
      - niftich 10y ago
        Both of you are correct, just talking about different things. PBKDF2 rounds are clearly sequential. Meanwhile, you can issue multiple simultaneous requests in parallel to try to authenticate the credentials, possibly from a large bank of distinct hosts.
jldugger 10y ago
> Yeah, after 3 failed attempts, just lock the user for 1 second. Do human users authenticate faster than once a second?
- DonaldFoss 10y ago
  Assuming a web page, does the page reload in less than 1 second? On a full sized keyboard, the normal rate is 3.3 key presses per second. On a mobile device, I'm sure an 8 character password will take far more than 1 second. For brute force attack defense, rate limiting a single account globally to 1/sec, i.e. independent of source IP address, should be sufficient and prevent parallel attacks by bots, but this still makes DOS attacks on a particular account easy, but not the entire system except traditional overload. Many API systems work this way and it's proven effective.
  - jldugger 10y ago
    So, why not always lock the page for 1 second post failure, rather than try to capture a 3rd strike policy?
- user5994461 10y ago
  The login page probably can't be loaded in 1 second ^^

Yeah, after 3 failed attempts, just lock the user for 1 second. Brute force still will lead nowhere and real users will hardly notice. I wonder why this didn't establish in the first place...

jjnoakes 10y ago

Why wait until 3 tries? Why not just require 1 second between all attempts?

blauditore 10y ago
Hmm, I guess this makes sense. Not sure what I was thinking...
viggity 10y ago
if you're hashing with PBKDF2 and 100k+ iterations, it can take that long anyway.
- tedunangst 10y ago
  But not in parallel.
  - sleavey 10y ago
    Can hashing iterations be conducted in parallel? Doesn't the next hash need the output of the last, making this a sequential operation?
    - niftich 10y ago
      Both of you are correct, just talking about different things. PBKDF2 rounds are clearly sequential. Meanwhile, you can issue multiple simultaneous requests in parallel to try to authenticate the credentials, possibly from a large bank of distinct hosts.

jldugger 10y ago

> Yeah, after 3 failed attempts, just lock the user for 1 second. Do human users authenticate faster than once a second?

DonaldFoss 10y ago
Assuming a web page, does the page reload in less than 1 second? On a full sized keyboard, the normal rate is 3.3 key presses per second. On a mobile device, I'm sure an 8 character password will take far more than 1 second. For brute force attack defense, rate limiting a single account globally to 1/sec, i.e. independent of source IP address, should be sufficient and prevent parallel attacks by bots, but this still makes DOS attacks on a particular account easy, but not the entire system except traditional overload. Many API systems work this way and it's proven effective.
- jldugger 10y ago
  So, why not always lock the page for 1 second post failure, rather than try to capture a 3rd strike policy?
user5994461 10y ago
The login page probably can't be loaded in 1 second ^^