Login |

Question

I was provided with some code from another developer who created some login security policies. For example, if you try to log in with a username that exists in the database, it will begin to record the number of failed logon attempts. Then, after he has reached 3 login attempts, he adds another log entry, but adds bit 1 to LockedOut.

Do you guys think this is a good security policy? Is it that someone trying to gain access will just try a large number of random usernames and forcibly block everyone from their account? This seems like a bad security philosophy.

I would think that a more effective protection procedure would be to block everyone who made 3 attempts according to the IP table, which tracks various user attempts and expires after 30 minutes or so, to prevent DDoS.

How do you guys design your entry security? Here is what this developer did basically:

if username is in database: if first login: increase fail-attempt counter. if second login: lock out username. else: don't let him in. else: incorrect password. 

edit: Final procedure:

 public void ResolveTimeouts() { if (data.Expire <= DateTime.Now) { // it will only delete ONE single entry from the database, // that happens to be this user IP // If and only if, The expiration date is older than right now. Delete(this.data); data.Attempts = 0; } } int uid = UserExists(username); if(uid < 1){ ResolveTimeOuts(); // this will delete IPs from table if expiration passed if(loginAttempts >= 3){ "Fail login, you have been locked out for " + TIMEOUT + " minutes"; ExtendExpiration(TIMEOUT); } else { IncrementAttempts(); "fail login, incorrect username or password."; } } else { if(authenticate(uid, password)){ "Successfully logged in."; } else { // INSERT lock out specific username feature here. "failed login, incorrect username or password."; } } 

Answer 1

I do not agree. I feel that blocking a username is generally safer (excluding IP).

What happens when a malicious hacker spoofs an IP address? A hacker can navigate IP addresses and constantly brute force username.

I am blocked after three attempts in 15 minutes.

Comments on your board:

I would do something like this:

 if(resolveTimeOuts()){ bool uid = UserExists(); //do other stuff }else{ "Your IP has been locked. Enter this code to prove you are human." // Captcha or math equation. } 

Although, I would not delete expired IP requests in resolveTimeOuts() . This may increase the execution time of the function. Do something like this:

 if(resolveTimeOut()){ bool uid = UserExists(); //do other stuff }else{ "Your IP has been locked. Enter this code to prove you are human." if(rand(1,5) == 5){ // or something equivalent deleteExpiredRequests(); } // Captcha or math equation. } 

This would ensure that resolveTimeOut() executed resolveTimeOut() , and if the IP requests too quickly, all expired timeouts will be deleted. A double hit view for a DoS hacker. They get another page, and page generation can be slowed down through deleteExpiredRequests() if there are a large number of expired.

Edit two: This is more or less what I would use. I would write the full code, but I program in PHP.

 bool function humanRequest(){ // decide if the request lag is humanistic or bot speed // for example: last_request > this_request - 500; } if(!humanRequest()){ // redirect to a Captcha page or die with a warning or something (like SO does) } uid = getUsername(username); if(uid > 0){ // validated request } else{ // increase attempts // you could have a separate column for IP requests or whatever // lock out username after 3 attempts } 

You could put humanRequest() in both cases of validating the username. Basically, if they ask for a username in a short period of time, black list them. But if you check the usernames on a special page (which is only included when someone tries to log in), this will already take care of this.

Thus, you only need to add another table. There is no need to modify the table you have.

Answer 2

The best of the two worlds approach I have seen is to use Captcha in the form after unsuccessful login attempts.

This allows a real user who may have honestly forgot his password to continue trying, albeit more slowly, to effectively stop automatic attacks using brute force. This makes the number of IP addresses that an attacker uses inappropriate.

Answer 3

I prefer to limit the number of login failures for a certain period of time, then either temporarily disconnected the user or refused to accept additional logins from this IP address for a while.

The goal of the exercise is to prevent brute force attacks.

Answer 4

Instead of delving into my personal philosophy, I put aside people who think about proper security and nothing more.

However, there are certain guidelines and standards that are accepted as best practice. I suggest starting with OWASP: http://www.owasp.org/index.php/Guide_to_Authentication

The usual pattern is to disconnect the user after a certain number of attempts over a period of time to prevent brute force. The usual standard that I saw in practice in well-written web applications is 3 invalid attempts, which lead to a 1 hour lock.

By the way, a specific locking issue is spreading on the OWASP website here: http://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Account_Lockout

Quote from the article (bold added by me for emphasis):

If an attacker can guess passwords without considering the account has been disabled due to unsuccessful authentication of attempts, this provides an opportunity to attack a brute force attack until the account is compromised.

Automating brute force / password guessing attacks on web applications is a trivial task. the password should use locking mechanisms that block the account if more than a specified number of failed logins are attempted.

Password locking mechanisms have a logical weakness. it is possible for an attacker a large number of authentication attempts to find out the names of known accounts, as a result of which entire blocks of user accounts of applications are blocked.

Given that the purpose of the password blocking system is to protect against brute force attack, a reasonable strategy is to block accounts for the number of hours. This significantly slows down the attackers, accounts must be open to legitimate users .

Answer 5

The compromise should be to block for a short period of time, to significantly slow down automatic attacks, but not too long for a legit user who made a “legitimate” mistake. IMHO, in most cases, 10 seconds may be enough if a forced password policy is respected .

Answer 6

If you serve corporate clients, you cannot block users by IP. Corporate firewalls tend to hide the IP addresses of users from a web server. Three unsuccessful attempts by all three users behind the firewall can block the entire organization (or one really stupid user who never checks to see if his locks are locked if pressed).