"26 x 26 x 26 x 26 x 26 x 26 x 26 x 1 = 8,031,810,176"

I think that's a bit wrong. You've got 7 26's there instead of 8 and a 1 instead of 10: 26^8 x 10^1.

You raise a very good point. It's something I haven't done but it defiantly something I'm going to do in the future.

I wonder if all OpenID provider have time delays on login attempts?

> eight character all lowercase, ending in 1

I think it's correct. Password in the form of:

abcdefg1

- 8 characters total
- all lowercase
- ending in 1

OK. I misread. I thought it was 8 alphas plus 1 (any) numeric. My bad.

It's 26^7x1 because he assumes 1 is the most common last part of any password."password1" was the most common password from the linked article, as well as slipknot1, qwerty1, soccer1 and basketball1.

For websites, I put my trust in passwordmaker.org plugin, unique cryptic password for every site I need to log into. And I just need to remember 1 master password.

I have taken to using YouTube IDs as passwords. If I forget my password, I just check out the video.
Explained here:
http://www.snowstone.com/archives/000479.html

Great article! its about time more people start using openID

So, if I want to DOS a particular Twitter user I don't like, I would just need to fail a login to their account a few times per minute?

The problem with throttling is that it's hard to implement correctly such that it doesn't invite harm to legitimate users. You have to pay attention to the source of the attack, which can be challenging given large caching proxies.

"every rinky-dink website on the planet demands that I create unique credentials especially for them"

Hopefully the rise of OpenID will mean that this happens fewer and fewer times. More convenient for the users, more secure for everyone (as long as the OpenID providers get it right).

"It's more typical for each failed login attempt to take longer and longer, like so:"

and add a good captcha after the third failed attempt.
(Thinking of re-captcha or similar here)

@Alex Scordellis

We have to hope that all OpenID providers implement some sort of throttling on the account.

I bet the larger ones like Google, Yahoo and AOL do. But what about the smaller providers?

Login attempt throttling should be part of the OpenID spec which to my knowledge, isn't.

The best way to protect your account from this type of account is to use a long well mixed password.

Don't know about anyone else but I tend to use the same credentials for forums and similar things, because i am not too bothered if it gets hacked its only going to give them at most my email address, as I put in made up details for everything else.

It saves a lot of remembering passwords which I think is a big problem for everyone since every other website needs a login. I use much better and unique passwords for stuff banking and so on. If lots of people do similar things it would probably adjust the results.

Minor problem with the MySpace survey. It preselects users vulnerable to phishing attacks. Presumably, people with stronger passwords would also be less likely to appear in this set. This skews the results toward the "bad password" point that you are trying to prove.

Still, a good lesson that we can teach our non-techie friends. Let's all point them toward Super Gen Pass.

I recently tried changing my password at a famous ISP (I won't mention names, but it rhymes with girth-wink). They're policy is:

* Capitalization matters (make sure CAPS LOCK is turned off)
* Your password must be between 6 and 8 characters
* It can contain letters and numbers but no symbols

I don't know if they have any throttling, but I think it would be a good idea--especially for the making that policy! ;-)
--dang

Oops--"their", not "they're". Time for some coffee.
--dang

Hmmm... is there any throttling for adding comments to this blog?
--dang

Hey Now Jeff,

Gotta love those password charts!

Coding Horror Fan,

Catto

"This can lead to denial of service attacks, however, and is generally discouraged. It's more typical for each failed login attempt to take longer and longer"

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.

Even more secure is the captcha after a few tries, as stated by Schalk Versteeg.

Additionally, sites should reply with something like "username and/or password incorrect", instead of pointing out if the username was wrong or if the password was wrong.

Even if there has been much improvement on broadband connections, it's mostly in regard of bandwidth.
It takes time to reach the twitter server, send an http request, and get the result. My guess is that in the best of circumstances, it would still take 50 to 100ms to try just one password.
I think the weakness here is more that the password was extremely easy to find with a dictionary attack and with only few attempts. A slightly more elaborate password could have required much more time, even with unlimited login attempts.

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.

@configurator

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". :)

Increasing throttling each time still seems like it would make it easy for an attacker to forcibly lock someone else out of their account.

Inspired by the Twitter hack, I wrote up a technique for implementing rate limiting without having to store every attempted access in a database (using memcached counters) last night, along with an example implementation: http://simonwillison.net/2009/Jan/7/ratelimitcache/

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 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..

I think another point that doesn't appear to have been made is that the hacker in question evidently knew the account name of an admin at twitter. It's not enough to know passwords, you also have to know what account to apply them against. So in this case there were extenuating circumstances:

1) He knew an account name of one of the users.
2) That account had a week password.
3) That account also had admin privileges.

I wonder if there is more to this story than meets the eye?

I also agree that consistently bumping the amount of the delay leads to DOS for legitimate users. I can imagine that on any given day dozens of idiots are tyring to login as Obama just for the hell of it. So the delay should be no longer than 10 seconds or so. But this is long enough to twart a standard dictionary attack.

I think the real concern here is that Barack Obama has a twitter account... where does he find time for these things?

Why not use something like this?
http://danger.rulez.sk/index.php/bruteforceblocker/
I'm sure you could make something similar to work with login attempts from a website. Give them so many to try, then after that they can request the password be changed and if they keep attempting to brute force it just block them at the firewall. I know this isn't an option for larger sites right now because of some visitors being behind corporate or ISP NATs, but I believe that problem will get smaller as we implement IPv6.

Well if you know that every wrong login will take longer then you just use rotate the usernames instead of the passwords, so that this won't get triggered as quickly.

<blockquote>Given the average user's password choices -- as documented by Bruce Schneier's analysis of 34,000 actual MySpace passwords captured from a phishing attack in late 2006 -- this is a pretty scary scenario.</blockquote>
This has been pointed out a lot before, but phished passwords are not a valid sample for studying the wider population of users. They might actually be "average" passwords, but we have no way of knowing this with any certainty. It's just as likely that the average password in the phished sample is vastly inferior to the password of the average user who was not susceptible to phishing.

I ran a site with 100k members and a 4 char minimum for password. 10% of my users had the password 1234.

I changed the minimum to 6 chars. Later I checked, and 10% of my users had the password 123456.

Progressive login delays are a good idea, but if you implement this naively in ASP.NET (i.e. using Thread.Sleep) then I think it will block, won't get returned to the pool, and you open up your whole site/app pool to a very easy DoS.

Presumably if you spin off a non-pooled thread, make that one wait, and have the ASP.NET worker thread wait on that, it will get returned to the pool and you won't have issues, but I'm not positive. Has anybody tried this, or does somebody know of a better way?

A few items to note.

Use a locally stored password management tool like KeePass to store all your passwords. These tools can generate strong passwords. It might sound like a pain if you use multiple computers, but you can put the program and database on a USB Flash drive. Portableapps.com has a Portable KeePass, and others.

Passwords aren't very secure anyway. Many web sites have easily circumvented password reset methods. Use of SSL certificates, or private keys is much stronger, especially if they are passphrase protected as well. With a passphrase required to unlock the certificate or key, you now have two-factor authentication, which requires something that you *know* (password) and something that you *have* (private key file).

OpenID provider myopenid.com allows use of a client certificate to authenticate. It doesn't support a passphrase, but the cert is installed in the client browser. A revokation method is available as well if you suspect your private key has been compromised (ie, your laptop was stolen).

@Jasmine
Barack only used the twitter account during his campaign to communicate to voters. Post election he hasn't used it at all (too busy) and for purposes of the Presidential Records Act, which puts his correspondence in the official record and ultimately up for public review, and the threat of subpoenas.

"it will block, won't get returned to the pool, and you open up your whole site/app pool to a very easy DoS."

I think the delay should not hold the connection open, it should terminate with a message that the user should retry in X seconds - whether the password was good or not.

Let's forget the English language. Let's say any user could have a password with any of the 96 printable ASCII characters and that password could be any length between 1 and 40 characters. Two questions:

1). How many possible passwords could there be?
2). How long would it take for a new computer to go through all possible combinations?

BONUS:

3). If I was a serious hacker, would I only use a single computer to crack the password or use a whole rack full of servers?

For answer #1, I am not sure how many possible passwords there would be. You'd have to add all combinations between 1 character and 40 characters to figure that one out, and I am just to lazy to do it. But it's safe to say there are a whole lot of them.

For answer #2, I would say it shouldn't take longer than a week or two to go through every single one of those combinations. Buy enough computers, and you could do the crack in one day no matter how obscure the password.

There was a time when Unix use to store the encrypted password visible in the /etc/password file. "Hey, it's encrypted.", everyone thought, "How could that be a security hole?". Sure, someone could use a supercomputer to figure it out, but a $3000 IBM PC? It would take thousands of years. Besides, they don't have enough memory to pull it off.

Well, those PCs got faster and faster, while memory and storage grew from kilobytes to megabytes to gigabytes. Enter the first dictionary attacks. You could easily encrypt an entire dictionary, run a hash from each encrypted entry to each cleartext entry, and then find a match in the /etc/password file.

Soon, the passwords were stored in a "root only acessible" file, users were encouraged, and sometimes required to add in numbers and other non-alphabetic characters, have at least one character that is upper case and one that is lower case. Some even went so far as to ban any password that contained an actual English word. The random string of letters "qd6?7c.s3d/fishfus34v@@f" would be an invalid password because it contains the word "fish" and "us".

However, the faster computers are, the faster they are in guessing every possible combination of characters. There use to be a program called "crack" that did just that too. A System Administrator would run it on their password file, and see which users had poor passwords. As computers got faster, dictionaries got larger and larger. Now, we are at the point where even completely random passwords are guessable.

What is required is to make sure computers can't guess all the passwords. That's why a delay.

I disagree with Jeff Atwood's method though. First problem: Users would grow frustrated each time they enter their wrong password, and had to wait 8 to 16 seconds for another attempt. They may simply switch to another service. It's a overkill. A simple one second between each login request and the server's response would be more than enough to prevent any dictionary attack.

Of course, having the delay just between incorrect login and password combinations is not really a good idea. A hacker would quickly detect the delay, know their login and password combination is incorrect, and then simply start a new HTTP session and try again.

The CORRECT way to do this is always have a one second delay between the initial login request and the response even if the password is correct. That way, a hacker doesn't know whether the combination worked until they wait for the full delay. One second is short enough for users to barely notice and long enough to prevent a dictionary attack.

Of course, a Hacker could simply spawn a few billion requests at once, but that would probably overwhelm the server as it tries to process them all. So, for now, you're pretty safe.

However, as machines get faster, bandwidth increases, and servers can handle bigger and bigger loads, this type of attack too must be taken into account. Security is an arms race between those who must protect their systems and those who want to break into those systems. What was good enough security last year is this year's security hole.

Did anything happen to the hacker? It's still illegal to do this as far as I'm aware.

I would go with the method of maybe for the first 2-3 times increase the login time but only to a max of say 4 seconds, maybe less.

Then any attempt after that use a refreshing captcha.

I will have user login on a new site of mine and will probably do this.

I was going to go with OpenID but I don't think it would have any benefit considering my audience.

>I think another point that doesn't appear to have been made is that the hacker in question evidently knew the account name of an admin at twitter.

According to the article, the hacker didn't know it was an admin account until he was "in."

>He found Crystal only because her name had popped up repeatedly as a follower on a number of Twitter feeds. "I thought she was just a really popular member," he said.

>That's when he realized that Crystal was a Twitter staffer, and he now had the ability to access any other Twitter account by simply resetting an account holder's password through the administrative panel.

VMS had a great login security feature.
After 3 bad login attempts it still gave you the login box and let you make as attempts as you liked - except it ignored them.
While keeping you on the line long enough to be traced (VMS was used by people that could do that!)

Rather like Joel's - deleting threads but letting only the poster still see them.

Just curious (you never know, I may have to implement security for a web site some day and I don't want to be one of the dumb ones!), but from a technical perspective, where would you implement the delay? Presumably you can't put it in the client code because the hacker would just bypass it, but it you put it in the server code, don't you just risk having your entire site DOS'd by tying up all of your server threads in sleep calls?

Is there some clever way of putting in a delay which doesn't tie up your server resources?

The delay is totally useless window dressing. it is unlikely that an attacker is going to focus energy on a single account. Typical attacks would likely distrubed and looking at trying to attack lots of accounts and passwords looking for any way to achieve access. If I know there is a delay I am likely to try an account every nth time. if my attack is broad enough i might try only every other hour and not even be noticed or impacted with a delay.

Its like someone walking through a neighborhood trying car doors to see if they are left unlocked.

Twitter should be running a dictionary attack on all admin accounts to ensure high quality passwords are being used by trusted accounts. This sort of process is easy for them to run and more extensive checks can be done whenever the password is changed.

I use Joel's method of Password Gorilla and DropBox (http://www.joelonsoftware.com/items/2008/09/11b.html). The only issue I have now is finding a client for my G1. Although I can export the PW list as text onto DropBox. Yeah, I know it's not optimal :)

Would it not also be useful to implement a check against the top insecure passwords when the user creates their account or changes their password?

Along with your usual rules of "must be at least X chars long" etc, compare the hash of the password to the hash of the most common passwords, and prevent the user from re-using such a common value.

Obviously it wouldn't be practical to have a massive dictionary list to compare against, but a reasonable list of the most common password would still be useful.

An inverse-dictionary check, so to speak.

@David W:

I think you don't have much of a sense of scale.

Let's assume the 40 character passwords, and that the latency of the network is 40 ms (which is pretty typical for my cable connection), everything is done in 1 packet exchange and no latency for other resources, such as CPU and disk.

That is approximately 1x10^62. In what units you ask? Age of the universe.

Now add in 39 character, 38, 37....

That's a lot of computers needed to brute force everything.

To David W, when you say
>For answer #2, I would say it shouldn't take longer than a week or two to go through every single one of those combinations. Buy enough computers, and you could do the crack in one day no matter how obscure the password.

With 96 char and a lenth of 40 char, you can have 40^96 passwords... In pratice, it's big. The univers does have something like 10^80 atoms. In pratice, it will be hard to build enougth computer ;)

@the comments supporting openid

The only problem I have with openid (and its proliferation) is that you're putting all of your bags in one basket. If your openid gets hacked; you're potentially pooched.

If you think "well I'll just get multiple openid accounts" well then you're back to the same problem of having a bunch of name/password combos to have to remember. People have enough trouble remembering the important ones they need to remember now as it is.

I guess the benefit is that at least you know the company storing your name/pass.

@ David W. re: old Unix passwords

IIRC, the passwords were stored encrypted with a salt. The salt is there to prevent dictionary attacks.

A dictionary attack is where the attacker pre-computes a dictionary of encrypted passwords. This is presumed to be the time-consuming task.

If the attacker uses the frequency of words or other heuristics, and simply throws them unencrypted at the login service, that is a brute-force attack.

If the attacker obtains a file of encrypted salted passwords, then the salt is visible (unencrypted). Searching the dictionary space with a chosen password's salt and comparing to the encrypted value in the file is, again, a brute-force attack.

This is part of the reason I've switch to fingerprint readers on my computers. I can pick a unique, complex, lengthy password for each separate website, and the fingerprint scanner will remember it.

Not mentioned in the article is the effect of policies that force users to change passwords every 30 days. I believe these policies lead users to choose simpler, more predictable, more sequential passwords. I would rather have a user pick a strong password once, and guard it closely.

I'm especially appalled at banks that have card PIN numbers where they are:
1. only numbers
2. must be exactly four digits long

Then there are the websites where you try to use a secure password and they respond by saying:

"You cannot use the '#' in your password." This is a bad sign in so many ways.

The one thing I do not and will never understand is *maximum* password requirements. Why do we put such terrible limits on what a password can be?

For instance, my bank (of all people) requires my password be no longer than 12 characters and cannot contain any symbols. It's a bank people! If a password is all I have between my financial information and someone trying to steal it, why can I not make my password 30 characters longer, upper case, lower case, numbers and any symbol under the sun?

I've resulted to using a password manager and now I try to use a different password for *every* site I need to log in to. And if they site lists the password req's on the registration page, I generate a password that will meet their max requirements.

You know what else kills me? Sites that make me register but do not tell me what my password can and cannot include. They make me submit the page just to find out in size 36 bolded red text that my password is in-fucking-correct. Thanks a lot!

I meant to add...

If you're looking for a killer password manager setup - look no further than Dropbox and Keepass. Keepass has a client for virtually every platform (although their iPhone client is still in beta, that is slowly driving me insane). When I had a Blackberry, my passwords were always at my fingertips.

It's a good thing the ASP.NET built in membership provider has a passwordAttemptThreshold and passwordAtttemptWindow.

It locks the account after passing the threshold.

<a href="http://msdn.microsoft.com/en-us/library/system.web.configuration.membershipsection.aspx">http://msdn.microsoft.com/en-us/library/system.web.configuration.membershipsection.aspx</a>

You may be limited to a few passwords a day on a 'single' website but don't forget most users will use the
same password accross multiple websites, and are likely to be registered on several of the same kind of websites. Think.. digg, reddit, slashdot, myspace, facebook, bebo, etc..

you get the idea.

Delay a login attempt response means use more server resources, a connection open for example and this can lead to a DOS...

....i've always been a fan of the password 'password'.... ;-)

(a) Several sites have "password too weak, try again" on the "register" section, but in the options section on the change password page, it is simply - old password, new password, confirm new password.
What's the use?

(b) This struck me as usable (after modification): We (people who do not crack) could make a updated list of IPs and publish ranges and _patterns_ of IPs from where mass-logging attempts originate - use spam-fighting methods to identify IPs.
Drawbacks:
1. IPs can be spoofed.
2. IPs change frequently (as much as per minute or faster)
3. Botnets are used, effectively framing clueless users on the basis of IPs
Each of these can be taken into account and have been thought about well by spam fighting software. (I haven't read much about OpenID so these are raw ideas)
For example, webmaster1 tells webmaster2:
From UTC 20090109.010644 to UTC 20090109.022755, my server got this list of multiple login attempts:
1.2.3.x | 3.67 times per login
3.x.4.5 | 4.58 times per login
...
etc

It can be done, parameterized properly, and he has a program that filters out important IPs (again a local or shared list)
It becomes a cat-and-mouse/hide-and-seek game. That makes them work much harder. Reduces the Noise in the cracker attacks - only the really intelligent crackers will be able to work.
If this is not incorporated into OpenID, then it should be.
Because we cannot afford to overload the network with DDoS-style data from script kiddies.
The big bad guys do enough damage, as it is. Maybe we should cut out the noise and make life easier by getting a narrower range of attackers.
Any W3 recommendations for Security Audit Standards?
"Hackersafe" exists, but I've heard it isn't all that reliable.

http://www.google.com/search?q=howto+strong+password

Many folks above talk of the anguish of "maximum length" for passwords.
Possible reasons:
1. Some managers (or Finance MBA types) wanted to micromanage/nitpick the password system and all they were comfortable with were alphanumeric passwords.
2. These sites have databases designed back then, when computing power was expensive and database sizes were crucial to cost-cutting or ROI - these need rewrites, but nobody dares touch running code and the audit requirements are fixed, although the world has changed to elect Obama, and the audits are passed successfully every year! Customers? who cares, we'll see that case-by-case, when we reach there.
3. Conspiracy theory:
The site _wants_ that some people have access to your data with no strings attached - at all. But given the way the village idiot worked things out (of order) this is not necessary.

In cases 1 and 2, "Change must come to America!" Let's Hope!

All of you hip surfers out there, there's a common p455w0rd list out there too, which can be made by simply substituting the leet alphabets with the corresponding l33t digits.

It's done wayyyyy back in those days of the Pentium, so 'p455w0rd1' isn't really much safer than 'password1'.
Use a book and keep a paper. One folded paper where all your web passwords - *N*O*T* BANK PASSWORDS - are written neatly.

And keep that password paper behind your spouse's photograph in your wallet/purse. Treat it like your Passport - priority item.

Here's the table template:
(Ctrl+P for print)

|--------|----------|----------------------|
| Site | date | password |
|--------|----------|----------------------|
| y! |20090109.1|M4r yhad ali Ttle l4mB|
| g |20081225.1| dOnt youz "XMAS tree"|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
|--------|----------|----------------------|

By the time you've finished reading this, someone's already published a nursery rhyme collection of passwords in English and 133tspeak.
But then the Oxford has been around for ages.

But the paper is as valuable as your Passport. And Jesus will punish you for keeping the paper outside on the table. No really.
St. Peter will deny you Heaven if the Lord's secret, which is on your password paper, is read by someone else!
It's between you and Jesus.

Umm... I *hope* that will be of some help1234.

Since we're on the subject of web security fail, I thought I'd post this:

https://visa.com

I think delaying response is a bad approach. Why not just use an expirable lock-out with growing expiration intervals instead? If a user genuinely tries 4 passwords (i do that often when i don't remember) he'll have a response time of 8 seconds? Why not just tell the user he'll only be able to attempt another login in 8 seconds instead?

>> visa.com

oh, that's wicked - I typed it into the addressbar directly to make sure it wasn't a JS trick or something; just wow...

OpenId is a great solution, however it's only supported by a handful of the (probably) thousands of sites I've registered at throughout the years.

By registering at a site we place some trust in them (kind of like can you hold on to my wallet while I tie my shoelaces.) Unfortunately they keep our wallet forever.

I know it would be smart to create a 32 character completely random password for every login, but how the hell would I be able to remember 32*1000 passwords? I would probably have to write it down. I could use a piece of paper for that, but that's obviously unsafe. I could store them on a keychain, but then I will have ONE password protecting all my information.

Gosh, that's not a good solution.

Or a hacker could stand behind the highest ranking google officer when he types in the password for the ace account.

The point I'm trying to make is that whatever protection one human comes up with, a hacker human can get around.

It's of course no excuse for weak passwords and servers with weak protection.

> Delay a login attempt response means use more server resources

No, you just return immediately and let the user know (via javascript countdown) how long until they can try again. This is all tracked on the server, obviously.

> If you think "well I'll just get multiple openid accounts" then you're back to the same problem of having a bunch of name/password combos to have to remember

So the answer is either one or infinity? I smell a logical fallacy. How many forms of ID do you have in your wallet right now? If it's more than one, the world has failed you! Reality: multiple forms of ID is fine, as long as it's a smallish number. They really do serve different purposes, exactly like what's in your wallet (or purse) right now.

> This is part of the reason I've switch to fingerprint readers on my computers.

http://www.dansdata.com/uareu.htm

> many sites I visit specifically tell me that my password MUST be alphanumeric.

This is the great advantage of OpenID: you outsource your username/password to a company that ISN'T retarded. There are providers which offer two-factor auth, even!

I have used delays in the response period, but it was always geometric, not exponential. Just delay=attempts*seconds. And because I was using the ASP sessions to track attempts, they had to time out their session to reset the count. If they weren't handing me back the unique session cookie I set on the login page then I wouldn't validate it at all.

I agree that delays breed DoS attacks and using up resources. It also assumes that the user is using the same session to track the attempts.

One method that I have used in the past is to have the script that builds the login page randomize the <input> variable names for the login and password and store them in the session info. Then I use that to pick them up again. It's much harder to make the password guessing program if it has to get the login page, parse it for two variable fields, then apply the guesses against the randomized variable names when resubmitting.

Another idea is to use the users own login id as the salt to the hash for the password. That eliminates rainbow attacks, even ones customized to your site.

I also don't limit the length or characters used in a password. The only thing that goes in the database is the hash, so I don't have to worry about length or character limits.

I concur with not giving admin access through the main website. We have used a separate url with additional firewall source requirements. That's key.

But, keep in mind that no matter how tightly you lock the front door, one of two things can still happen: Someone will ultimately break it down or someone will sneak in the back door. Most data losses either happen outside the system (unsecured ftp transmission of database backups?) or from someone internal to the system. We can't prevent it 100%. It's more like The Club. Not perfect, but good enough to make someone keep moving to the next target.

For my bank, it always warns me that my account gets blocked etc. if I get the password wrong 3 times. This made me chuckle, because I always use the wrong user name with the right password.

>> And because I was using the ASP sessions to track attempts, they had to time out their session to reset the count. If they weren't handing me back the unique session cookie I set on the login page then I wouldn't validate it at all.

This just requires a call to load the cookies from the login page, then pass that to the form; minor inconvenience.

>>Then I use that to pick them up again. It's much harder to make the password guessing program if it has to get the login page, parse it for two variable fields, then apply the guesses against the randomized variable names when resubmitting.

Look for the login form, then assume that the first input that's displayable is username and the second one the password (or template it based on the adjacent html). Minor inconvenience.

Now consider ip-blocking after 3 login attempts - sucks for AOL, but you only get to spam the login 3 times per box you control. The refinement here is to use a botnet and spam slowly and across a large set of usernames. Best defense there (I think) is to track auth failure percentages by IP and when they hit 20% over some time period, put them on the always fail list.

Oh yeah, and just today we saw a teacher at school type her password right after her username. She tried to logon into the medical records system (I study medicine) to show some X rays of a patient.

Approximately 300 students have seen her username and password.

And yes, it ended with the number 1.

Too bad I've forgotten the rest already...

Yes, there's many many problems that are possible with login throttling.

However, in the case of an administrator account, a little bit of agressive throttling is perfectly ok, because its a slightly important account. They can avoid the denial of service issue by throttling attempts from outside the office much more aggressively than they throttle attempts from inside the office.

For particularly serious attacks, there's always SSH'ing into the actual server to do the administration stuff.

Also, the admin's "doing admin stuff" account should be seprate from their "doing normal user stuff" account. So even if you can post 'I'm a dumbass' over and over using the admin's account, you should have a higher bar to pass before getting unlimited access to the user database. Such as, for example, a properly set up SSH connection, so you need private keys as well as passwords. And, hey, a 1024 bit private key is a little bit harder to guess than a 40 character "strong" password.

I have heard of a couple of people having their hotmail accounts hacked, then being sent emails to their work email account asking for payment to get their hotmail email account back. This is happening all the time.

Personally I've been a fan of Bruce Schneier since reading his Applied Cryptography book back in 1999. It still has pride of place on my book shelf and I consider it a minimum read for anyone trying to secure anything. Even if the encryption standards have moved on, the processes, protocols, and hack methods all remain the valid.

BUT - my main reason for posting is that passwords don't work. I don't like them and I don't want them - heck I can't even remember them. Sometimes I find myself saying "what was the birth date of my... no... it was the maiden name of my... uhhhh... or was it my first dogs name... no... the first street I lived on... ahh I didn't really want to get into that site anyway".

Passwords can be cracked/hacked/gained through brute force or social engineering. Heck - most of the users in the work place seem very happy to give their user name and password to other users, even though it is the same password they use for their personal web logins. I don't like biometrics either. If someone is able to duplicate a biometric then you are royally stuffed (what are you going to do – cut yourself a new finger print or get some plastic surgery???). Biometrics signatures can be stolen “in the pipes” and if that happens the hacker doesn’t need your biometric – they have the signature of your biometric and that’s all they need.

Why the heck aren’t we using digital card logins – the ones that have the numbers that change with time? The technology has been around for a decade and is now standard for bank web page logins. An admin login for a high profile web site should be secured to this level.

>> Why the heck aren’t we using digital card logins – the ones that have the numbers that change with time? The technology has been around for a decade and is now standard for bank web page logins. An admin login for a high profile web site should be secured to this level.

this might be enough to make me use an openID like thing - sign up for an account, get your RSA token, and sign into random_web_site with a username/token value. If the site steals it, so what? it's good for a minute only, and if someone hacks my account, they don't really have access to all my sites - i still have the key. I still need to trust the authentication agent, as they could go poof and then I'd be boned.

> Why the heck aren’t we using digital card logins – the ones that have the numbers that change with time? The technology has been around for a decade and is now standard for bank web page logins. An admin login for a high profile web site should be secured to this level.

Verisign offers this feature for OpenID.

https://pip.verisignlabs.com/

Meaning, you could sign into any OpenID supporting website with two-factor auth.

> > Delay a login attempt response means use more server resources

> No, you just return immediately and let the user know (via javascript countdown) how long until they can try again. This is all tracked on the server, obviously.

Tracking it on the server means more server resources. Durr

The other thing to protect against is attacks where the username changes for each attempt. (For example, if you don't care which account you get into, try several different usernames with "password" as the password. This is very common against SSH servers, but could also happen against a web site such as eBay or a bank.)

This is harder, because you have to limit based on source IP address, which means someone could forge the source IP and deny service to legitimate users.

@Obviousness:

Wow, 4 whole bytes per user.

Jeff -

You've got some sort of bug in your counting of English words in the OED. The first edition, published in 1928 defined 414285 words. The 1989 edition defined about 615000 words. There may be more.

>I still need to trust the authentication agent, as they could go poof and then I'd be boned.

Good point. Bruce Schneier points out that both parties - in this case the one logging in and the web site - have to equally trust the third party authenticator more than they trust eachother.

So if you don't trust the authenticator either... like you said, you are boned.

> Tracking it on the server means more server resources. Durr

I believe the OP was referring to literally *pausing* and holding open a connection on the webserver and client for (n) seconds.

trustno1

> 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.

My car radio has a pin if power is lost and does the increasing delay trick. Ticks me off royally. Like someone would even try to steal a tape deck radio in this day and age!!!

Still - it is very effective.

Hey how about Facebook Connect? Everyone put their personal data on Facebook more accurately than any other thing such as OpenID.

Why don't we all use Facebook for credentials?

One billion of chinese hackers decided to break a Pentagon server by brute forcing.

Each and every hacker decided to try a password 'MaoZedong'

On the 486,384,485th attempt the server gave up and agreed that its password really is 'MaoZedong'.

It is my answer to twitter's lesson:
http://jack.lifegoo.com/fail-to-ban-lesson-from-twitte

Who cares? It's twitter.

I was also concerned about delay, but your suggestion to store the time at which one user will be able to log in on server side seems interesting.

Are you already doing it somewhere? I'd like to see an implementation of this.

I wondered why Barack was trying to tweet me ... I was like come on man, don't you have to be working on that presidential gig you're doing?

Good run through of the tips. I figured most social sites should know the key patterns and practices by now, especially for dictionary attacks. I can understand getting some of the more advanced stuff wrong -- it is complicated.

I was working on a threats and countermeasures KB a while back (http://www.guidanceshare.com/wiki/Threats_and_Countermeasures ), and it has a lot of the basics, but it would be worth elaborating some day.

>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.

Already been done, against Norwegian banks, which have predictable numeric user IDs. You keep the password constant and change the user ID, since each account only gets one password attempt recorded against it per given time unit the usual lockout doesn't get triggered.

>If you're looking for a killer password manager setup - look
>no further than Dropbox and Keepass.

Just make sure you capitalise the latter appropriately. KeepAss has rather different connotations to KeePass.

And all those websites have different rules. One requires no numbers, another requires one number, still another requires two numbers in the password. This site is case-sensitive, that one isn't. This site demands special characters, the next one forbids it.

I had to think up my first password in 1976. To this day, no account that I used with that password was broken into. Only one other person knew that password in case something should happen to me. I divorced her last year and have been using a new password scheme since before then.

Of course the other idiocy is requiring numbers in the USERNAME. I mean, if you want to, fine. But I have a pretty unique combination of letters that I've been using for a username for 28 years.

All these different unique and sometimes mutually-exclusive rules increases the risk of a person doing the number one worst thing you can do for security - writing a password down.

>>At one attempt per second, that would take more than 250 years. Per user!

Who said that???

I can use few hundred Virtual Machines each will try to login, or even use the Grid to do so for me :-) I can ask users on the Grid to download my small utility and millions of users will do the hack for me in just few hours.

It's hard..but not impossible ;-)

>>I can use few hundred Virtual Machines each will try to login, or even use the Grid to do so for me :-)

Each machine is still waiting about a second for the turnaround. Also, if you use a botnet you'll risk overloading the authentication server and thus drawing attention to yourself.

The real story at Twitter was that they didn't check their own passwords. You can't trust people to use good passwords, you have to run a password checker against their accounts and force them to change lousy passwords.

eBay needs to read this. My account there got cracked into last year, and my password was definitely not dictionary-attack-vulnerable -- they have to be lacking throttling too. I only found out about it because the crackers used it to send out spam messages to other members, recording the outgoing messages in my outbox.

"every rinky-dink website on the planet demands that I create unique credentials especially for them"...

How would a rinky-dink website be able to check whether your credentials were created uniquely for them? I bet you could just use the same password for all your accounts.

My password everywhere is "jeffattw00dsuX0rs"

Now you just have to figure out my user IDs, and you can post indiscreet pictures of your wife in my name.

(Hint: one of my user IDs is "jeffattw00dsuX0rs1")

> You have to run a password checker against their accounts and force them to change lousy passwords.

An excellent point; you should *absolutely* dictionary attack your admins before someone else does!

You might also block regular users from entering extremely common passwords, gently prodding them to pick something else. Or add "1" to the end. :)

Given some of the hilarious messages he posted on Twitter as these celebrities, maybe we should be thanking this Twitter hacker:

http://www.globalnerdy.com/2009/01/05/maybe-its-time-to-update-your-twitter-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).

Thanks. I knew something didn't sound quite right.

For the variable delay, you could have it delay if the password is wrong.
For example, if the password is wrong on the first try it would be a 0 second wait.
Even if the hacker attempted hundreds of times, resulting in the hacker taking an extended time period with 2^X, if the user logs in correctly the first time then there is no wait.

If we are using ASP.NET Membership stuff, we could simply look at the amount of bogus tries and do a delay ( System.Threading.Sleep() ) in code instead of a redirect.

This limits the hacker but allows the user to go by oblivious.

I would argue that after some quantity of failed log in attempts (let's say over 400) within a short time span (let's say, 24 hours), that *some* kind of alert should have went to someone but maybe I'm just overly paranoid. I would further argue that the user should be notified as well just in case they need to investigate other sites. If a user is foolish and chooses one password for all their sites then everything is now compromised.

Salts don't stop attackers from using precomputed tables, per se, they just make the precomputed tables larger. The standard 12-bit salt makes the table 4096 times bigger, which looks like a lot, but really isn't.

They also don't do a whole lot for stopping brute force attacks, since even with an infinite length salt, you can still crack the passwords one at a time.

We provide the facebook hacking services but also we could hack yahoo passwords, or crack hotmail email account password. Check out our website http://www.activehackers.com

Hey, the delay-trick is pretty cool, why i havent heard about it proviously? I think this is way more user-friendly than disabling the account and requesting a new password. I think the best dictionary-attack i a combination of dictionary and bruteforce-attacks in the following way:

-take a word from the dictionary
-add a series of numbers and/or non-alphanumerics at the beggining and end
-test

<num/non-alphanum> <dictionary word> <num/non-alphanum>

This increases the attempts per word, but the most passwords are generated like this.

Hi, this is the first time that i put my opinion in this blog. I'm from Argentina, so my english is not very well.
Many times when i search something to download, this require login, and i'm so lazy and always put password like:

The WebSite Name like www.website.com

USR: website
PWD: website

Or passwords like:

ALASKA
ALASKA

Some passwords never change, but this is a administrator-problem not a user-problem.

I hope that my opinion be a good opinion.

Agustin Polito

MTZ --
If you've ever forgotten your password to a shell account on a *nix machine, you'll notice that it always takes a few seconds to return from a failed login attempt. It's definitely a great trick.

I've heard that most passwords are composed of 1-2 words and a symbol, either between the words or after them/it. Breaking away from that pattern can help ($w!ord%sent3nc_e:?!), but I've found myself generating 12-character randomized passwords and keeping them in Password Safe instead: http://www.schneier.com/passsafe.html

Just a minor what not: 1 password guess per second is a extremely poor estimation.

The estimate is that a modern Core2Duo can try roughly 10,000,000 passwords a second.

Noone else has mentione it, so I will.

Dictionary Attack != Words from a real dictionary. It's even in the first two sentences of the wikipedia link you use. A dictionary attack doesn't use the Oxford English, or Websters, or anything else. It merely used a "pre-defined list". This predefined list is often composed on the most common passwords and weighted in some sort of priority based on what you know (or think you know) about the users.

So it is very likely that it did not take your theoretical two days. It probably started with 7 - 9 character passwords and took much less than two days to find the password for clueless wonder.

Any IT person who gets caught with a password like "happiness" should be summarily fired and blacklisted, never to work in our field again. Talk about gross negligence....

This is not an easy problem at all. There is a balance between secure and unusable and no I'm not advocating being a twit about it either.

Their are some real problems with some of the solutions mentioned:

* back off algorithms
Sounds nice but it's just plain pants. How many times have you cussed the digital gods when you mistakenly type your sudo password ( *nix heads ) wrong and have to wait that endless 3 secs. Painful! OK it slows down the attacker ( if based on account not session see below ) but it will lose you some members for sure. Every usage report shows you how much we hate waiting online.....

* openID
CAN EVERYONE STOP SAY THIS SOLVES THE PROBLEM! It potentially makes it worst. Great I do not know what openID provider 'Bob@stackoverflow' uses. So why not simple DOS ALL the openID providers in the list. Get 1 openID account get access to all these other sites.. Cookie jar or what!

* CAPTCHA + google + yahoo
Simply cleared your cookies and refreshed the page after your 3rd attempt? Yes that's right it's a cookie based check not server side for obvious reasons... In case it's not obvious if it were server side you would need to record each failed login. This would require writes [ to DB / cache ] which are expensive and in fact would make the DOS even more effective especially when all the writes bring your site to a halt.
Code wise dumping of cookies after nth attempt is trivial.

The problem is identifying an attack against a genuine user with a sticky return key. You can't trust the remote machine and server side is expensive. Block IP is a waste of space as any hacker worth their salt will perform a distributed attack ( not to mention dynamicIP used by ISP's ). Plus the added fact that WE the consumer care less about passwords and more about what we want to consume which is why I can't even remember the password to my own site.

Did I hear someone say remote pin pricks / breath analyzers Gattaca style?

@imoan

update: Google's CAPTCHA at least is now also server / cache side as well. Bahh! They have the money to do that though.. still doesn't change my point.... <mumble mumble>

I wrote about this issue a few weeks ago on my blog. However my concern was the too strict and sutpid lock out policy implemented by the 'serious' systems (think banks, corporate intranet, etc.) For some reason the guys who design these systems think that the number of trials should be three. No more, no less. And it makes impossible to have a few guesses. Add to this that these systems usually mandate a password change every know and then, which circumvents using strong passwords. Most users will change just one digit anyway. However if you can't remember that your password is number one or two know then you're out of luck with three tries. What do you do after the first failure? Try to retype or try the alternate versions? You can try both but only if you don't make any more mistakes...

Giving 50 tries wouldn't decrease the security, but the nest solutions if of course slowing down the attack (to avoid the DoS you mentioned).

I really don't see the point of having any kind of authentication at all on the vast majority of websites. For example, there is no benefit to the user for having an unguessable password on stackoverflow.com, as opposed to one that is published on Bugmenot.com. Likewise, there is no benefit to the user for giving out a verifiable, permanent e-mail address, as opposed to one that's going to be deleted as soon as the confirmation link arrives.

There is, however, a benefit to the Web site: The Web site's owner gets an opportunity to build a database of verified e-mail addresses, which can be sold to spammers for some extra income.

OpenID, then, is part of the problem, not the solution. When one OpenID provider becomes the most popular, that OpenID provider will have a database larger than those of all the small sites that currently have this data. This provider could command a hefty fee for a subscription to this database, but there would be no benefit to OpenID users.

For Web site users, the best solution would be if most Web functions were unauthenticated.

@imoan
re: CAPTCHA + google + yahoo
(...) if it were server side you would need to record each failed login. This would require writes [ to DB / cache ] which are expensive and in fact would make the DOS even more effective (...)

Actually, that's not exactly the case. You don't log every failed attempt to the database, only the ones that 'count'. Meaning the ones that happen after the waiting period is over. Let's say I set a waiting period of 20 seconds that is activated after the 5th failed login attempt. Those five logins get stored to the database (an incrementing number of failed attempts and a timestamp logging the last failed attempt).

Now, during that period - the 20 seconds - I don't log anything. If the attacker, a botnet or the user tries to login during that time, I merely return an error message telling him to wait for a bit until the fog clears. I don't even care whether the password is correct or not, he has to wait 20 seconds either way.

Once the waiting period is over, the next login attempt will be authenticated as usual. If it checks out, the user (presumably) is logged in. If the password is incorrect, the account enters a new 20 second waiting period right away, since the user's 'failed logins' counter is still greater than 5 (or whatever my limit might be). That way, the 20 second limit thwarts rapid-fire dictionary and brute force attacks, and the server-side suspend period makes sure DoS attempts don't get to write to the database more than once every 20 seconds.... which isn't going to bring my server to a halt ;-)

So which is better for the delay?

A: System.Threading.Sleep(delay) on the response
B: Map w/ datetime used to deny attempts for the delay period.

Hey Jeff,
What software do you use to create your charts?
Thanks,
Tim

Probability of denial of service after failed login attempts would also be reduced by checking IP address. While it would be possible for attackers to use multiple IP addresses this wouldn't increase attack rates by more than a few bits - at least in IP4.

http://google.com

oh, it fine