Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm currently working on reducing the risk of mass account lockout on a site that (unfortunately) issues sequential, numeric user IDs. Changing the structure of the userID is not an option at this point.

I've looked at a few options (CAPTCHA, Restrictions on login attempts per IP). One think I am thinking about is the use of an anti-CSRF token on the login page, requiring an attacker to load the login page (and get the token) prior to any login attempt. This would probably be combined with a delay before the token would be accepted (several seconds, the time taken for a regular user to enter login details).

This would not prevent lockout, but it would slow down the rate of attempts, and slightly increase the complexity of performing the lockout. Has anyone seen this used before? Would it really work?

share|improve this question
add comment

3 Answers

I personally never saw something like this implemented, but why don't you set up a time increasing failed login ?

For example, after three unsuccessful login, you block the login for this account for, say, 30 seconds. After the 30s, if the 4th login is still unsuccessful, you stop it for 1min, then 5min, and you increase more and more.

This won't affect your real users (you generally don't fail 3 times if you remember your password, and if you don't, you go to the "Lost my password" process), and robots will fail using a brute force attack.

Now, the CSRF idea is interesting for forcing your user to get the token, but if I build a robot, I still can simulate a GET request to the login page, parse the HTML and get the token, to then use it for a POST combined with the credentials. The only limitation you suggest here, is the wait between the generated token and the submitted form (and this could hurt your users that are fast writers).

share|improve this answer
    
"This won't affect your real users" Hug? If a real user can't login for 5 min or more, that doesn't affect him? –  curiousguy Jun 19 '12 at 20:26
    
@curiousguy - A real user stops after being locked out for 5 minutes and simply resets their password. –  Ramhound Jun 20 '12 at 11:02
    
@curiousguy : This affects users that fails to login more than 3 times in a row. Do you know some of them? Mine just reset their password after 3 failed login or less... You need to differentiate reality and probability. –  Cyril N. Jun 20 '12 at 15:24
    
@cx42net "This affects users that fails to login more than 3 times in a row. Do you know some of them?" Yes, it can easily happen for a bunch of reasons. "You need to differentiate reality and probability." I have no idea what you are talking about. –  curiousguy Jun 20 '12 at 15:51
add comment

I've seen something similar being used for preventing comment spam. Take a look at cookies for comments wordpress plugin if you need some inspiration. Quite a useful plugin. It's simple but very effective. Sounds like essentially the same principle as your idea.

The basic concept is providing a hard-to-predict value via a form/cookie and expecting to see it back within a time-constraint to prevent automated bot attacks.

share|improve this answer
add comment

Delays are a reasonable application-layer rate-limiting strategy for protecting bot-sensitive interfaces in general. You could use an authorisation token as part of that strategy, for example an HMAC-signed token that includes an issuance timestamp, or a timestamp in the session if you're using sessions.

requiring an attacker to load the login page (and get the token) prior to any login attempt. This would probably be combined with a delay before the token would be accepted (several seconds, the time taken for a regular user to enter login details).

That delay would have to increase as more and more tokens were issued, to effectively act as a queue that allows no more than one login attempt per X seconds for a particular source (typically single IP, or netblock). Otherwise an attacker could just request a hundred auth tokens and submit them all at once a few seconds later.

Determining what that X is, and monitoring good and bad behaviour from different sources to adjust that X for different addresses (either manually or in code), is potentially a significant ongoing process.

share|improve this answer
    
"a particular source (typically single IP, or netblock)" yes, but it is difficult to define "source" in IPv6 –  curiousguy Jun 19 '12 at 20:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.