11–14 of 14 posts
It's important not to create new attack vectors that don't already exist when implementing security features.
If you don't throttle accounts that don't exist then a brute force attempt can be used to determine which logins are valid for a given service. This information can then be combined with targeted phishing attacks, etc.
How do you implement a failed login delay? I assume you'd have to just sleep before sending the response. But this could tie up all available threads for processing requests and bring down the site under heavy attack.
You refuse to allow login during the delay period. That is, after the 5th failed login, for the next 16 seconds, if the user tries to login, you say "Wait sometime before trying again." You do not accept and check the credentials supplied during this time. You simply refuse to begin the authentication process until the delay period has elapsed.
How do you implement a failed login delay? I assume you'd have to just sleep before sending the response. But this could tie up all available threads for processing requests and bring down the site under heavy attack.
You refuse to allow login during the delay period. That is, after the 5th failed login, for the next 16 seconds, if the user tries to login, you say "Wait sometime before trying again." You do not accept and check the credentials supplied during this time. You simply refuse to begin the authentication process until the delay period has elapsed.
i.e., if me simply knowing someone's account name lets me disable their account for the next day or longer, that's a big problem.
Margo: Precisely what you're paid to prevent.
The Plague: Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and...
Margo: [glares at The Plague]
The Plague: God. So, would your holiness care to change her password?