This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Server-Side Login throttling schemes
Server-Side Login throttling schemes

Version management

Difference between version and

At line 1 added 64 lines
!!! Overview[1]
[{$pagename}] are [Best Practices] are a [Throttling] method and a [Security Consideration] for combating [Brute-Force] [Attackers]
!! When an [Attacker] is coming from a single IP Address
First, have a look at the numbers: [Password Recovery Speeds - How long will your password stand up|http://www.lockdown.co.uk/?pg=combi&s=articles|target='_blank']
If you don't have the time to look through the tables in that link, here's the list of them:
* It takes virtually no time to crack a weak password, even if you're cracking it with an abacus
* It takes virtually no time to crack an alphanumeric 9-character password, if it is case insensitive
* It takes virtually no time to crack an intricate, symbols-and-letters-and-numbers, upper-and-lowercase password, if it is less than 8 characters long (a desktop PC can search the entire keyspace up to 7 characters in a matter of days or even hours)
* It would, however, take an inordinate amount of time to crack even a 6-character password, if you were limited to __one attempt per second__!
So what can we learn from these numbers?\\ Well, lots, but we can focus on the most important part: the fact that preventing large numbers of rapid-fire successive login attempts (ie. the brute force attack) really isn't that difficult. But preventing it right isn't as easy as it seems.
Generally speaking, you have three choices that are all effective against brute-force attacks (and dictionary attacks, but since you are already employing a strong passwords policy, they shouldn't be an issue):
* Present a [CAPTCHA] after N failed attempts (annoying and often ineffective)
* Locking accounts and requiring email verification after N failed attempts (this is a DoS attack waiting to happen)
* finally, login throttling: that is, setting a time delay between attempts after N failed attempts (yes, DoS attacks are still possible, but at least they are far less likely and a lot more complicated to pull off).
!! Best practice #1
A short time delay that increases with the number of failed attempts, like:
* 1 failed attempt = no delay
* 2 failed attempts = 2 sec delay
* 3 failed attempts = 4 sec delay
* 4 failed attempts = 8 sec delay
* 5 failed attempts = 16 sec delay
* etc.
DoS attacking this scheme would be very impractical, since the resulting lockout time is slightly larger than the sum of the previous lockout times.
%%information
To clarify: The __delay__ is not a delay before returning the response to the browser. It is more like a [timeout] or refractory period during which login attempts to a __specific account__ or from a __specific IP address__ will not be accepted or evaluated at all.
%%
!! Best practice #2
A medium length time delay that goes into effect after N failed attempts, like:
* 1-4 failed attempts = no delay
* 5 failed attempts = 15-30 min delay
DoS attacking this scheme would be quite impractical, but certainly doable. Also, it might be relevant to note that such a long delay can be very annoying for a legitimate user. Forgetful users will dislike you.
! Best practice #3
Combining the two approaches - either a fixed, short time delay that goes into effect after N failed attempts, like:
* 1-4 failed attempts = no delay
* 5+ failed attempts = 20 sec delay
Or, an increasing delay with a fixed upper bound, like:
* 1 failed attempt = 5 sec delay
* 2 failed attempts = 15 sec delay
* 3+ failed attempts = 45 sec delay
This final scheme was taken from the [OWASP] best-practices suggestions (link 1 from the MUST-READ list), and should be considered best practice, even if it is admittedly on the restrictive side.
%%information
As a rule of thumb however, I would say: the stronger your password policy is, the less you have to bug users with delays. If you require strong (case-sensitive alphanumerics + required numbers and symbols) 9+ character passwords, you could give the users 2-4 non-delayed password attempts before activating the throttling.
%%
DoS attacking this final login throttling scheme would be very impractical. And as a final touch, always allow persistent (cookie) logins (and/or a CAPTCHA-verified login form) to pass through, so legitimate users won't even be delayed while the attack is in progress. That way, the very impractical DoS attack becomes an extremely impractical attack.
Additionally, __do more aggressive__ throttling on admin accounts, since those are the most attractive entry points!! [LDAP and Bind Throttling]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [The definitive guide to form-based website authentication|http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication|target='_blank'] - based on information obtained 2016-08-10
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop