*
programming and human factors
by Jeff Atwood
*
Several high profile Twitter accounts were recently hijacked:
An 18-year-old hacker with a history of celebrity pranks has admitted to Monday's hijacking of multiple high-profile Twitter accounts, including President-Elect Barack Obama's, and the official feed for Fox News.The hacker, who goes by the handle GMZ, told Threat Level on Tuesday he gained entry to Twitter's administrative control panel by pointing an automated password-guesser at a popular user's account. The user turned out to be a member of Twitter's support staff, who'd chosen the weak password "happiness."
Cracking the site was easy, because Twitter allowed an unlimited number of rapid-fire log-in attempts.
"I feel it's another case of administrators not putting forth effort toward one of the most obvious and overused security flaws," he wrote in an IM interview. "I'm sure they find it difficult to admit it."
If you're a moderator or administrator it is especially negligent to have such an easily guessed password. But the real issue here is the way Twitter allowed unlimited, as-fast-as-possible login attempts.
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.
Based on this data, the average MySpace user has an 8 character alphanumeric password. Which isn't great, but doesn't sound too bad. That is, until you find out that 28 percent of those alphanumerics were all lowercase with a single final digit -- and two-thirds of the time that final digit was 1!
Yes, brute force attacks are still for dummies. Even the typically terrible MySpace password -- eight character all lowercase, ending in 1, would require around 8 billion login attempts:
26 x 26 x 26 x 26 x 26 x 26 x 26 x 1 = 8,031,810,176
At one attempt per second, that would take more than 250 years. Per user!
But a dictionary attack, like the one used in the Twitter hack? Well, that's another story. The entire Oxford English Dictionary contains around 171,000 words. As you might imagine, the average person only uses a tiny fraction of those words, by some estimates somewhere between 10 and 40 thousand. At one attempt per second, we could try every word in the Oxford English Dictionary in slightly less than two days.
Clearly, the last thing you want to do is give attackers carte blanche to run unlimited login attempts. All it takes is one user with a weak password to provide attackers a toehold in your system. In Twitter's case, the attackers really hit the jackpot: the user with the weakest password happened to be a member of the Twitter administrative staff.
Limiting the number of login attempts per user is security 101. If you don't do this, you're practically setting out a welcome mat for anyone to launch a dictionary attack on your site, an attack that gets statistically more effective every day the more users you attract. In some systems, your account can get locked out if you try and fail to log in a certain number of times in a row. 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, like so:
| 1st failed login | no delay |
| 2nd failed login | 2 sec delay |
| 3rd failed login | 4 sec delay |
| 4th failed login | 8 sec delay |
| 5th failed login | 16 sec delay |
And so on. Alternately, you could display a CAPTCHA after the fourth attempt.
There are endless variations of this technique, but the net effect is the same: attackers can only try a handful of passwords each day. A brute force attack is out of the question, and a broad dictionary attack becomes impractical, at least in any kind of human time.
It's tempting to blame Twitter here, but honestly, I'm not sure they're alone. I forget my passwords a lot. I've made at least five or six attempts to guess my password on multiple websites and I can't recall ever experiencing any sort of calculated delay or account lockouts. I'm reasonably sure the big commercial sites have this mostly figured out. But since every rinky-dink website on the planet demands that I create unique credentials especially for them, any of them could be vulnerable. You better hope they're all smart enough to throttle failed logins -- and that you're careful to use unique credentials on every single website you visit.
Maybe this was less of a problem in the bad old days of modems, as there were severe physical limits on how fast data could be transmitted to a website, and how quickly that website could respond. But today, we have the one-two punch of naive websites running on blazing fast hardware, and users with speedy broadband connections. Under these conditions, I could see attackers regularly achieving up to two password attempts per second.
If you thought of dictionary attacks as mostly a desktop phenomenon, perhaps it's time to revisit that assumption. As Twitter illustrates, the web now offers ripe conditions for dictionary attacks. I urge you to test your website, or any websites you use -- and make sure they all have some form of failed login throttling in place.
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.
passwordy on January 8, 2009 1:16 AMSince we're on the subject of web security fail, I thought I'd post this:
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?
Bobby on January 8, 2009 2:09 AMvisa.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...
Cooney on January 8, 2009 2:19 AM
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.
lajos on January 8, 2009 2:28 AMDelay 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!
Jeff Atwood on January 8, 2009 2:28 AMI 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.
Chubber on January 8, 2009 2:30 AMFor 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.
alwin on January 8, 2009 2:38 AMAnd 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.
Cooney on January 8, 2009 2:39 AMOh 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...
alwin on January 8, 2009 2:43 AMYes, 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.
Bob on January 8, 2009 2:54 AMI 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.
Cooney on January 8, 2009 3:24 AMWhy 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.
Meaning, you could sign into any OpenID supporting website with two-factor auth.
Jeff Atwood on January 8, 2009 3:59 AMDelay 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
Obviousness on January 8, 2009 4:00 AMThe 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.
Mikel Ward on January 8, 2009 4:08 AM@Obviousness:
Wow, 4 whole bytes per user.
Rob on January 8, 2009 4:11 AMJeff -
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.
Philip on January 8, 2009 4:39 AM26 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.
David A. Lessnau on January 8, 2009 4:42 AMYou 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?
Stephen Hill on January 8, 2009 4:46 AMeight 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.
David A. Lessnau on January 8, 2009 4:48 AMIt'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.
Stle Undheim on January 8, 2009 4:48 AMTracking 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.
Jeff Atwood on January 8, 2009 4:48 AMI 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
Bhaarat on January 8, 2009 5:01 AMSo, 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).
Alex Scordellis on January 8, 2009 5:07 AMIt'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.
Stephen Hill on January 8, 2009 5:18 AMDon'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.
pete on January 8, 2009 5:22 AMMinor 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.
Michael L Perry on January 8, 2009 5:26 AMI 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
Catto on January 8, 2009 5:36 AMThis 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.
ZuBsPaCe on January 8, 2009 5:38 AMEven 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?
dhanson865 on January 8, 2009 5:56 AMA 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.
rcresswell on January 8, 2009 6:01 AMI 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...
configurator on January 8, 2009 6:02 AMPassword 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.
Ryan Meray on January 8, 2009 6:15 AMEven 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 on January 8, 2009 6:19 AM@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.
Practicality on January 8, 2009 6:20 AMAnd 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. :)
jheriko on January 8, 2009 6:40 AMOn 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. :)
Zack on January 8, 2009 6:42 AMI 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)
Meh, I just use 'orange' as my password.
Astrochicken on January 8, 2009 7:14 AMI 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.
Andr on January 8, 2009 7:16 AMI can hear the trolls rumbling in the distance...
Jeff Atwood recommends you DOS your favourite websites!
David on January 8, 2009 7:25 AMPersonally, 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 on January 8, 2009 7:25 AM@J. Stoever
Now that we know it's 78 letters and a valid sentence, it might be possible to figure out.
;)
Practicality on January 8, 2009 7:30 AMCracking 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)
Practicality on January 8, 2009 7:36 AMThis 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..
ThunderWolf on January 8, 2009 7:37 AMI 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.
Matt on January 8, 2009 7:38 AMI think the real concern here is that Barack Obama has a twitter account... where does he find time for these things?
Jasmine on January 8, 2009 7:39 AMWhy 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.
Pacifika on January 8, 2009 7:44 AMblockquoteGiven 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.
Regis on January 8, 2009 8:10 AMMy 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.
Philip on January 8, 2009 8:12 AMA 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.
Regis on January 8, 2009 8:18 AMLet'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.
David W. on January 8, 2009 8:19 AMDid 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.
dean nolan on January 8, 2009 8:30 AMI 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.
Peter on January 8, 2009 8:32 AMVMS 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.
mgb on January 8, 2009 8:46 AMJust 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?
Mark on January 8, 2009 8:54 AMThe 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.
mikester on January 8, 2009 9:08 AMHey 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?
Rezuan Asrah on January 8, 2009 9:09 AMTwitter 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.
OldTimer on January 8, 2009 9:10 AMI 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 :)
nwahmaet on January 8, 2009 9:15 AMWould 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.
Giles Paterson on January 8, 2009 9:17 AM@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 ;)
Olivier de Rivoyre on January 8, 2009 9:31 AMOne 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'.
Eugene on January 8, 2009 9:43 AMIt is my answer to twitter's lesson:
http://jack.lifegoo.com/fail-to-ban-lesson-from-twitte
@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.
Steve-O on January 8, 2009 10:57 AM@ 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.
prng on January 8, 2009 11:05 AMI'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.
Steve on January 8, 2009 11:33 AMWho cares? It's twitter.
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!
Ryan R on January 8, 2009 12:02 PMI 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.
Ryan R on January 8, 2009 12:05 PMIt'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.aspxhttp://msdn.microsoft.com/en-us/library/system.web.configuration.membershipsection.aspx/a">http://msdn.microsoft.com/en-us/library/system.web.configuration.membershipsection.aspx/a">http://msdn.microsoft.com/en-us/library/system.web.configuration.membershipsection.aspxhttp://msdn.microsoft.com/en-us/library/system.web.configuration.membershipsection.aspx/a
Delay a login attempt response means use more server resources, a connection open for example and this can lead to a DOS...
Gaetano Mendola on January 8, 2009 12:34 PM....i've always been a fan of the password 'password'.... ;-)
Dan on January 8, 2009 12:36 PM(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
passwordy on January 8, 2009 12:43 PMMany 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!
passwordy on January 8, 2009 12:55 PMI 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.
giorgian on January 9, 2009 1:22 AMI 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.
J.D. Meier on January 9, 2009 2:37 AMeBay 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.
Atario on January 9, 2009 2:43 AMIf 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.
Dave on January 9, 2009 3:34 AMIf 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.
Dave on January 9, 2009 3:45 AMThis is only a preview. Your comment has not yet been posted.
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email
Posted by: |