Daniel ‘Dang’ Griffith you should try using my bank then. The ATM pin can’t be more or less than 4 digits and the website pin cant be more or less than 4 digits. Both are separate but neither will let you use alpha characters so the password space is very very small.
I mean what good is online banking if my password can’t be orange1?
A good form of security on social networking sites et al would be to require the user’s login name to be different than their screen display name. Attackers would not be given a free list of usernames to try to brute force.
I like Google’s method of adding a captcha after the third attempt like Schalk suggested. Also, sites should differentiate usernames from public display name / email address / etc. when possible. Take, for example, World of Warcraft: nobody knows my username. Not in the game, not in the forums, not anywhere. Only account management can know usernames…
Password lockouts are extremely frustrating when it is your own account and their password retrieval mechanism sends the notification to an email you no longer use. At that point, your only choice is to hack your own account.
So your ‘extending delay’ method is definitely preferable, because I can manage to try a dozen or so of my common passwords, albeit slower, rather than 5 or 6 and then getting blocked.
Even more secure is the captcha after a few tries, as stated by Schalk Versteeg.
Right, I meant to mention this – Google does something similar.
That makes it even easier to test a website for dictionary attack vulnerabilities: just try to log in, fail 5-6 times, and if you don’t see a CAPTCHA… that’s bad.
I guess, you should probably stop at something like 10 seconds after the first few unsuccessful tries, otherwise an attacker could still cause a DOS for a user thanks to throttling.
True – at least with CAPTCHA the user is just inconvenienced by a CAPTCHA and not sitting waiting 32 or 64 (or 128… etc) seconds to log in hoping your bot doesn’t trigger the next time interval! automated griefing…
@dhanson865: orange1 is not a good password! It’s too short. Try using something longer, like colours1, or fearful1. There are plenty of other ideas at http://www.esclub.gr/games/wordox/7.html … Just add ‘1’ to the end.
That is a very good point. One of the key points when we did work for the pharmaceutical industry was that in order for things to be secure enough both the username and password had to be such that only the user (and admins) would know them. In some cases, even the username had to be hashed so that only the user would know them.
What if you forget your username in those cases? Well, too bad, you lose your access.
This model would not work for the web, of course, but it does make sense to not share usernames. The unique combination of username and password is far harder to guess.
And yet despite all the obvious reasons why people should be using strong passwords, many sites I visit specifically tell me that my password MUST be alphanumeric. They won’t allow me to use strong passwords.
If you can get a list of usernames, it would be funny to try to pick a random password like happiness at a time and test it against all usernames.
With a login delay per user this could still get you some hits.
It’s tempting to blame Twitter here…
Yeah… it is their fault. Like you say this is Security 101. Brute force attacks are the easiest to pull of, and likewise the easiest to avoid.
I like your suggestion and used an increasing delay, in the past I’ve always used a fixed one, which is not quite as good. Being able to send one request a second is pretty acceptable to a human user, but for brute force attacks you are reduced to a mere 60 attempts per minute, by which time your IP will be blocked for spamming the server with attempts inbetween. Its not perfect… a clever user could work this out, get a new IP, and then attempt one a second, and given enough time, this could be used to crack a password. Luckily I generally use long passwords… my largest regular one is 18 chars and the shortest is 7 chars (because I can’t use more than 8 for that password… don’t get me started).
Thanks for the tip. I’ll definately be implementing this moving forwards. 
On a web site I created recently, I hit the user with a CAPTCHA after, I think, three failed login attempts.
Jeff’s CAPTCHA Server Control for ASP.NET at CodeProject…
http://www.codeproject.com/KB/custom-controls/CaptchaControl.aspx
And, no, it doesn’t just use orange.
I cobbled up a few ideas for the folks at Hacker News:
http://news.ycombinator.com/item?id=422981
Not as complete as it could have been, but because our company uses websenseless, openID based systems can’t be used from work, so stack overflow is unusable, even at lunch (but HN is visitable during lunch).
Maybe I’ll take the time to write something more clearly up.
Some ideas before I head out to work:
You want to avoid having admin accounts log into the website they administer. Ideally, you’ll have an administration site for the admins to break/unbreak things. Or if you must allow admins to log into the regular site, it should be done from inside the corporation. We have one large financial client (they’re in the fortune 100) who does allow some admin accounts to access the main site, but virtually all of them must be done from inside the corporate firewall (so they have internal IP addresses, and not internet/routable IP addresses). These admin accounts let customer support people mimic the end clients. The few that can be used from outside the firewall also need the number off the SecureID token as part of the login.
To avoid DoS attacks against users, you may wish to also consider blocking the attacking IP address for a period of time. You’ll need to verify things in your own production environment, because you may find, like at our corporate datacenter, the loadbalancers were misconfigured so that when the website tries to log the user’s IP address, we only get the load balancer’s IP address (IIS logs are that way, as well as internal logging done by the web application). I’m not able to get the loadbalancers fixed because there are 40-50 different web applications that can’t permit downtime for them to check out how to correctly configure the loadbalancers (hey, it works, and only Tang is complaining, therefore the problem is with Tang the Merciless).
If hackers can download your user database, and you didn’t salt your passwords, they can use rainbow tables to do simple lookups on what many passwords are.
http://en.wikipedia.org/wiki/Rainbow_table (also, read the external links)
Fortunately for sites like Twitter, we seem to be moving (for better or worse) toward an OpenID solution for most of the web. This is great for smaller sites. If Twitter used OpenID exclusively the blame for this would be completely offloaded to the identity providers.
On the other hand, this is probably not so good for users. If you pick a less than mainstream provider, or use your personal site (by hacking your site someone can replace your openid.delegate attribute) you effectively have no one to blame and no recourse of action.
The obvious choice is to pick a provider that doesn’t suck.
Meh, I just use ‘orange’ as my password.
I have used delays in the response period, but it was always geometric, not exponential. Just delay=attempts*seconds.
Which is… tada… ARITHMETIC PROGRESSION, not geometric (which is the same as exponential).
But you knew that.
I can hear the trolls rumbling in the distance…
Jeff Atwood recommends you DOS your favourite websites!
Personally, I only use letters in my password, no numbers or special characters.
On the other hand, it’s 78 letters, so even though it’s a sentence, I think that’d be rather hard to brute force.
@J. Stoever
Now that we know it’s 78 letters and a valid sentence, it might be possible to figure out.
Cracking the site was easy, because Twitter allowed an unlimited number of rapid-fire log-in attempts.
You know, for a site with a history of difficulty dealing with load issues you would think they would have already addressed this, just to keep from being DOS’d by scripts doing millions of login attempts*.
(* Assuming that login attempts are more intensive than regular page loads. They usually are, since they involve several database queries and often http redirects, but not always)
This is a hell of a article. Interesting reading.
But how is it possible to make infinitive login attempts without any special security?
Well it should be me…