Why passwords have never been weaker—and crackers have never been stronger

Thanks to real-world data, the keys to your digital kingdom are under assault.

Read the whole story

 

[ewelch]

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

What I want is sites to stop telling us how to do our passwords. I want spaces and phrases, not random letters and numbers. But most don't allow spaces, and often they demand they be fewer than 16 characters.

How about a sentence with spaces and punctuation? Then let people write something only they would know with a mnemonic word to remind them what it is?

 

[Smeghead]

I've been an advocate for a while now of creating a passwords from several words that otherwise have no association with each other. This results in a long password that's infinitely easier to type than alphabet soup (especially on mobile devices) and more importantly, easy to remember.

I was overjoyed to see that XKCD covered this a while back with his usual panache. It described it much more succinctly than I ever could.

Unfortunately, I've gotten to the point where I have far too many passwords to remember, and have taken to using a password manager for those that aren't so critical. Those tend to be complete gibberish that I don't have to remember and are as long as their respective services will allow.

 

[TunnelBear]

Most interesting article I've read on Arstechnica in years. I like the topic, length and technical depth.

 

[WaveRunner]

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

This is after the password database has itself been compromised. Back in the old Unix days all you had to do is anonymous ftp into a site and grab the /etc/passwd file. Now it's SQL injection that's the real problem. I guess the idea is to get the passwords from a low risk site, and hope it's the same password on something that may contain CC info like Amazon.com

 

[xoa]

I'm glad to see Ars give a more in-depth overview of this, given the number of stories this year. Your headline and subtitle are silly hyperbole (a 20 character random password is just as strong now as it ever was), but overall the article itself covered the bases. I do take issue with a few parts though:

No, SHA1 is not a secure hashing algorithm

There is a difference between an algorithm being cryptographically secure and being brute force resistant. They exist for different purposes (and adaptive hash algorithms build upon the foundation of a cryptographically secure hash). MD5 would be an example of a hash algorithm that is no longer considered secure after attacks were devised that dramatically reduced the complexity of a collision attack. SHA-1 isn't recommended anymore either but that's separate from what you outline.

But the benefit in improved security largely outweighs the investment, many security experts argue. Had LinkedIn engineers used Bcrypt, for example, Gosney would have been able to make fewer than 1,750 guesses per second.

Adaptive hashes usually support arbitrary slowdown (number of rounds can be selected as an input). The user can make them as slow or as fast as they wish based on the application needs, so it's not quite right to attach a single number. They can be made slower to keep a constant time in the face of increasing computational power, or faster if the tradeoff makes sense for a given system.

It's also important that a password not already be a part of the corpus of the hundreds of millions of codes already compiled in crackers' word lists, that it be randomly generated by a computer, and that it have a minimum of nine characters to make brute-force cracks infeasible. Since it's not uncommon for people to have dozens of accounts these days, the easiest way to put this advice into practice is to use program such as 1Password or PasswordSafe.

FWIW, I think a number of OSes do have built-in methods. The UIs aren't going to be as good but they can still generate strong passwords. The Keychain application on OS X for example can generate strong passwords based on a number of criteria, and ships with every machine. While lacking the integration, built-in options are free and universally available.

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation. That would simultaneously give people more security while being more convenient (and in this case the two go hand in hand). I hope Ars does a survey of options relating to that in the future.

 

[DotMasta]

intense stuff, great read. I'm glad i've switched to a 20+ character/symbol password, but it's a shame some sites don't let you use such long passwords...

 

[evan_s]

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

Nope. They aren't sending 8.2 billion passwords a second to the website to try logging in. They've got a copy of the database that contains all the passwords converted into a hash (gibberish) using an algorithm. They repeat that conversion process on their own computer and compare the result of their conversion to the copy that was stored in the database. When they've got a match they've recovered your password.

The article didn't mention it but I assume the easiest way to determine what algorithm they used is by testing against a known password. As long as they can sign up for an account then it only takes seconds to determine what hash was used. Run your known password for your account through all the common hashes and find the one that matches.

 

[Bitweasil]

If you're interested in playing with rainbow tables without having to download them, https://webtables.cryptohaze.com/ has a number web-accessible - you can access them without needing to pull down 1.5TB of data first (you do the computation locally, and the table searching remotely).

The article didn't mention it but I assume the easiest way to determine what algorithm they used is by testing against a known password. As long as they can sign up for an account then it only takes seconds to determine what hash was used.

In many cases, the password "in position" tells you a lot about it. If it's 40 characters long, it's probably SHA1. If it's got a $P$ prefix, or a $H$ prefix, or other common prefixes, you know the algorithm and the details. In most cases, a 32 character hex string is MD5 (at least out on the web). And, yes, as noted, if you can register an account, you can petty quickly figure out what they're using.

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation.

Multifactor is good, as long as you don't have your storage systems for that hacked (see RSA).

I'm a big fan of the Google Multifactor auth system - it seems to be quite solidly done, and has a bit of a tech giant behind it (though that alone isn't proof that it's done right, Google seems to be pretty good with their security stuff lately, especially when integrated with Chrome).

 

[evan_s]

intense stuff, great read. I'm glad i've switched to a 20+ character/symbol password, but it's a shame some sites don't let you use such long passwords...

The problem is that I'm betting you don't use a unique one for each site. No matter how secure your password is against brute force hacking all it takes is one site that you use that password on storing that stores that password in plain text to get hacked for your password to end up in a dictionary. Once it's in the dictionary it's not really any more secure than 1234.

Realistically, the only way to actually be secure is to use a password safe program and make sure your password to that program is secure.

 

[Boskone]

I've been using KeePass for several years now. I know very, very few passwords; the rest are randomly, uniquely generated and as long as the client will allow.

I would like to see a unified second-factor worked out. Multiple second-factors are a considerable physical inconvenience (where available at all), and frankly using my phone as a second factor is nearly as inconvenient; I like to ROM my phone, and every time I did with Blizzard I had to deauth my app, ROM it, reath, etc. It would be really nice to be able to have a single hardware token from a third party that all of the login sites (can) use.

 

[xoa]

What I want is sites to stop telling us how to do our passwords. I want spaces and phrases, not random letters and numbers. But most don't allow spaces, and often they demand they be fewer than 16 characters.

As a bare minimum this would be a reasonable place to start. There is no reason in 2012 (or years ago for that matter) to not accept effectively arbitrary UTF-8.

The article didn't mention it but I assume the easiest way to determine what algorithm they used is by testing against a known password. As long as they can sign up for an account then it only takes seconds to determine what hash was used. Run your known password for your account through all the common hashes and find the one that matches.

Beyond that and what Bitweasil said, if attackers gain access to a password database it's often true that they'll also have been able to see the business logic. Algorithms aren't meant to be secret anyway so there's no point in wasting resources or adding complexity trying to hide it.

 

[dagamer34]

Honestly, if you aren't using a password manager at this point, you either have very few logins (unlikely) or you are reusing passwords somewhere. I'd personally get LastPass over 1Password as it's web-based and lets you log into your account from anywhere. And since you are giving them money every month, they have extra incentive to not let their security lapse.

 

[evan_s]

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation.

Multifactor is good, as long as you don't have your storage systems for that hacked (see RSA).

I'm a big fan of the Google Multifactor auth system - it seems to be quite solidly done, and has a bit of a tech giant behind it (though that alone isn't proof that it's done right, Google seems to be pretty good with their security stuff lately, especially when integrated with Chrome).

Multifactor authentication is definitely a good way to go but I sure don't want to have a bunch of hardware tokens that I have to carry around to sign into different sites. I signed up for the Google system recently and it seemed decent. A text message to a phone is a pretty reasonable option that many people can use that doesn't require carrying anything extra. I wonder how much the cost is for google for the infrastructure to handle this and the cost of actually sending the text msgs. Sadly the only hardware token I have is from blizzard for their b-net system and I'm sure I'm not that unusual.

 

[chanman819]

I'm hoping that one day, we'll have an authentication system that won't require the equivalent of a one-time pad for every blog, forum, and online retailer I'm registered with, because a unique, randomly-generated password for every single site and service sounds awfully like generating (very short) one time pads to me.

 

[koolraap]

Part of the problem is the balance between user-friendly (AKA minimising support costs) and security usually leans too strongly towards making things easy to use. There are far too many sites that let you enter pathetically weak passwords; there are too many organisations that implement useless password policies.

I'm afraid this is one case where porn is way ahead. Length is, indeed, everything.

 

[ngativ]

Nobody likes the idea of remembering dozens of difficult passwords. So, this article confirms my thoughts about developers: Is always developer's fault.

That's why i use the infamous kwallet.

 

[evan_s]

I would like to see a unified second-factor worked out. Multiple second-factors are a considerable physical inconvenience (where available at all), and frankly using my phone as a second factor is nearly as inconvenient; I like to ROM my phone, and every time I did with Blizzard I had to deauth my app, ROM it, reath, etc. It would be really nice to be able to have a single hardware token from a third party that all of the login sites (can) use.

The technology for that already exists it just isn't widely used.

See the SID800
http://en.wikipedia.org/wiki/SecurID

 

[Canageek]

I'm wary of password managers; What happens if my harddrive crashes, or that webservice goes down? All of a sudden I'm locked out of everything.

My compromise has been using a few, not very strong passwords for the dozens of webfora and such I am on, that don't have money involved. Then unique, long, hard to remember passwords for anything that remembers my credit card, involves money or my identify.

Is this a bad idea, or an ok compromise?

 

[NavyGothic]

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

As others have mentioned, you're misunderstanding the relationship here. The brute force approach isn't used to try to directly access the service or website in question; it's used to crack a hashed password after that information has been made available via other means (eg. database hacks).

In very general terms;

1. Database of popular service is hacked, login and password info for a gazillion users is available
1a. If the passwords are stored in plaintext, gg. Proceed directly to step 3.

2. Brute force / dictionary / etc. attack hashes 8.2 billion words per second and finds any recorded hashes which match the word
2a. For unsalted password hashes, you now have the passwords for a majority of users of the service. In other words, only marginally more secure than plaintext.
2b. For salted password hashes, you'd need to repeat the process separately for each user

3. You now have the login and password for a large number of users. You can either use this in a number of ways;
3a. Access the account directly
3b. Try the same login credentials for other more valuable services
3c. Add all the passwords to your dictionary and make step 2 much more efficient.

It's 3c that this article is mostly concerned with. The large number of website hacks over the last few years have vastly improved the dictionaries used by crackers.

 

[zer0x1A4]

Okay, so it can try 8.2 billion per second. All a website had to do to foil that is to deny an more tries after 10 or so, no?

What I want is sites to stop telling us how to do our passwords. I want spaces and phrases, not random letters and numbers. But most don't allow spaces, and often they demand they be fewer than 16 characters.

How about a sentence with spaces and punctuation? Then let people write something only they would know with a mnemonic word to remind them what it is?

I have this problem with so many sites - particularly certain online banking sites/apps which should allow us to create the absolute longest passwords with as much entropy as possible (ie allow ALL letters/numbers/symbols) but instead they're holding us to 8 - 16 character passwords with no symbols allowed.

The problem now is not solely in the hands of the people creating their passwords too weakly. With the social aspect of our culture encouraging everyone to "share" everything openly online, it only takes someone with enough time and patience and determination to compromise some accounts. Aside from the Ars community, think of all the elderly people and uninformed/lazy/stupid people who are bound to use a weak password, reuse that password across many sites, use the same name for all of their usenames and email addresses, and perhaps post their "pet name" or other revealing information to say Facebook or some other public profile and then also use that same "pet name" as the response for password recovery...even if it is as low as 1 in 1000 that are this insecure, or higher, the end result is a significant number of accounts that can be fairly easily compromised.

Adding to the pain are the weak server security implementations plaguing sites and companies that have absolutely no excuse for it. All it takes is some small server holding usernames and passwords and email addresses (and possibly other sensitive data) to be hacked and those databases copied for the whole process to get started. I say small because they could fail to implement best practices with security due to lack of experience and perhaps resources. For companies like Sony, LinkedIn, and Blizzard there really is no excuse. Having viewed some of the password lists compiled from many of the hacks in the last year or two it is blatantly obvious that some people out there just don't get it at all, but even with a moderate to good password strength, the hackers cracking those database dumps have all the time they need with the actual file locally accessible and once they unlock them it is only a matter of trial and error. Personally I would start with the simplest passwords and look at the email address and other information associated with those and pretty much assume that if they used "password", "love", or "12345" then chances are they would reuse that password and email combination for many other services. Social Engineering using stolen accounts is a great way to then spread malware to or compromise other accounts of relatives/friends/co-workers of that person's account.

Finally, the fact that Ars ran an article today stating the breakthroughs with quantum computing just shows that the state of cryptography and password entropy is in for some serious shifts. The article spoke of using quantum computing technology to solve protein-folding problems much faster than traditional computers and analysis. Its only a matter of time until this same technology will be used by governments and/or criminal organizations to start cracking passwords and current cryptography implementations.

 

[bsiu]

I'm wary of password managers; What happens if my harddrive crashes, or that webservice goes down? All of a sudden I'm locked out of everything.

I have my keepassx file in Dropbox, and on a couple of pendrives around the house. Has saved my ass a couple of times.

Great article, Dan. Good to see such technical depth.

--B

 

[Braumin]

I'm wary of password managers; What happens if my harddrive crashes, or that webservice goes down? All of a sudden I'm locked out of everything.

My compromise has been using a few, not very strong passwords for the dozens of webfora and such I am on, that don't have money involved. Then unique, long, hard to remember passwords for anything that remembers my credit card, involves money or my identify.

Is this a bad idea, or an ok compromise?

If you look into some of the good ones like LastPass, they are pretty bullet proof. Your entire encrypted archive of passwords is stored on your computer, and in the cloud. You can also download it to anywhere for safekeeping (though it won't always be up to date).

So if the cloud goes down, you have a local copy, and if you lose your local copy, you have the cloud.

Also most websites have some sort of password reset mechanism, so even in the absolute worst case scenario, you could reset them.

Password managers are really the only solution here. You need one great password and it takes care of the rest.

 

[clubside]

I apologize if I missed it in the article, but is there a best practice for a site to store passwords given all this new information?

I'm about to launch a new site which will allow both user registrations and Facebook/Twitter sign-ups. Obviously I don't have to do anything with the third-party authentication, but for users who choose a new registration, if I'm running PHP and planning on storing an email address and password in a database what would be the best practice?

 

[snowboardorange]

Excellent article!

 

[acme_myst]

Nice article, it was a great read.

I like the topic, length and technical depth.

+1

That allowed him to recover the password in question by appending each word in his list to every other word in the list. The technique is simple enough to do, although it increases the number of required guesses dramatically—from about 26 million, assuming the dictionary Redman uses most often, to about 676 million.

Minor point, but this seems off by a factor of a million.

 

[.Darien]

Brilliant article. This is why I subscribe to Ars.

 

[VisibleUsername]

It seems to me that there are other significant issues that are often overlooked in password security. For example, at Ars Technica, your login name is visible to all users. Thus, if the password for a user becomes known, the login name needed to access that user's account is also already known. This also makes it easier to identify targets: because Ars users are identified by public login name AND whether or not they are active subscribers, hackers looking for financial details can limit their attack to the set of usernames as published on the site with the subscriber tag.

Protecting one's login name ought to be just as important as protecting a password, allowing for different login and password combinations for each site. That way, if a login/password combination for one site is compromised, the particular combination fails to work on any other site; furthermore, the attempt to brute-force all possible passwords (or possibly starting with similar configurations as explained in this article) for that login name will fail, because the login name for the secondary target is unknown.

Another unsafe practice seems to be that more and more sites use an email address as the login name, not only making it more difficult for users to obfuscate their login as many have a limited number of email addresses but also giving a potential attacker another vector of attack: the user's email account.

Should any of these issues receive the same detailed examination as the password itself?

 

[acme_myst]

Should any of these issues receive the same detailed examination as the password itself?

No. Trying to keep the username secret essentially amounts to increasing the entropy of the password that is used. You'd run into the same common problem, i.e., users that still re-use them across sites.

 

[mmaroti]

The solution would be for browsers to update how they stores and synchronizes passwords so people can trust it:

1) generate a strong random number for each site, store and synchronize this in the cloud as they store passwords now

2) let the user enter a weak password in the password field, but no autofill, since the password is never stored

3) combine the weak password with the strong random number, calculate a hash and send this as the password to the website

4) allow to export and import the random numbers to local files, so people can backup and move these as needed

This means that it does not matter if someone gets access to one of your accounts, they will not be able to access the other accounts. Also, you could safely reuse your password (as most people do).

 

[Vapur9]

My solution: don't store hashes as a single SHA1 or MD5 result ... combine it for further obfuscation. A hash is designed to fall into enemy hands, so don't make it easy to produce rainbow tables.

SAMPLE - All other password weaknesses still apply!


function generateHash($name, $pass)
{
$salt = '';
for($i = 0; $i < strlen($name); $i++) { $salt = $i . $salt . $name . $i; }
return (sha1($salt . $pass) . sha1($pass . $name . $salt));
}

 

[Dac]

Triffic article, I was impressed.

I did a password cracking exercise back in 2001 against 5,500 passwords, on a Windows server's NTLM store, and cracked 99.9% in a 'few days'. With this new tech, it would have been the work of a few minutes.

Now if only I could use 'random gibberish' to logon with initially [artificial restrictions, not able to use USB-key or other two-factor (something you own + something you know) solutions.]

XKCD's 'phrase generation' was excellent though. Microsoft's TechEd security guy was a huge advocate of 'drop passwords and implement pass phrases instead'. I think his passphrase was 27characters.

For me, it's the accuracy of typing (which is hopeless) which prevents me from regularly using 'long passwords' on key systems (i.e my initial home computer logon and my initial work computer logon).

Keepass is an excellent freeware password manager, I'm using it more and more. After reading this article, I'm going to switch all my various game accounts to using some manic Keepass generated password I can keep the Keepass database in the cloud if I need to have access to it 'somewhere else'.

</ramble>

So yeah, great article.

 

[vipervenom37]

I would like the author to address the xkcd.com comic on the subject: http://xkcd.com/936/

I tend to generate passwords by taking the first letter from each word in a somewhat nonsense sentence (i.e., rather than famous quotes) - it seems like that would also be a good way to get into the uncracked percentage in these major breaches.

I'm sure there are also other rules/techniques/strategies for generating a password that you have to remember that would reduce crackability, and I think it would be helpful to share those since it's more likely to get Joe Blow from accounting to remember correcthorsebatterystaple than it is to get him to a use a password program.

 

[pcgamer1206]

Holy. Crap.

Project Erebus can do in 12 hours what it would take my computer 7,500+ years to do.

Time for an upgrade...

 

[Braumin]

I apologize if I missed it in the article, but is there a best practice for a site to store passwords given all this new information?

I'm about to launch a new site which will allow both user registrations and Facebook/Twitter sign-ups. Obviously I don't have to do anything with the third-party authentication, but for users who choose a new registration, if I'm running PHP and planning on storing an email address and password in a database what would be the best practice?

Here is my suggestions as a synopsis of a recent Security Now! podcast:

Have a password strength meter right on the page in Javascript. It would be kind of cool if it included the top 100 bad passwords too, or you could just reject them.
Have any password requirements listed on the page where people have to create their accounts. Don't force people to use complex passwords though. If you have the strength meter then it is their decision to secure their account.

Hash using a good function like SHA256 or SHA512.

Use something like bcrypt, or something with a Key Derivation Function You want multiple passes, but you don't want it to take TOO long. Still it can likely be done all client side so there shouldn't be much work on your server end.

Use Salt. Unique salt per account. Store that with the password.

An additional layer of system wide salt not stored with the password would add some extra strenght if (when) the database is stolen because it would not be stored with the passwords, but it would be known to you.

Do lots of research! These are just some tips, but there are many smart people out there who know way more about this than me.

 

[mmaroti]

Password managers are really the only solution here. You need one great password and it takes care of the rest.

No, password managers are not the solution: if someone gets the master file and able to crack it, then they will be able to access all of your passwords.

You should NOT store passwords on your local file, but store very strong random numbers and combine that with your weak password and submit those to the website. This way an attacker cannot run brute force tests without working through the site where the password would be useful.

Unfortunately the password managers are providing convenience (you do not have to type in passwords for various websites), instead they should improve security (you still have to type in your password, but that can be week and will be combined with something strong).

 

[Vapur9]

Well, you need to make sure to warn after 3 to 5 failures, make users wait a period of time, and when a successful login occurs alert the user, demanding that they change their password or else reset it for them and maybe demand identification for the return of the account (since email can be hijacked).

 

[Braumin]

I would like the author to address the xkcd.com comic on the subject: http://xkcd.com/936/

I tend to generate passwords by taking the first letter from each word in a somewhat nonsense sentence (i.e., rather than famous quotes) - it seems like that would also be a good way to get into the uncracked percentage in these major breaches.

I'm sure there are also other rules/techniques/strategies for generating a password that you have to remember that would reduce crackability, and I think it would be helpful to share those since it's more likely to get Joe Blow from accounting to remember correcthorsebatterystaple than it is to get him to a use a password program.

https://www.grc.com/haystack.htm

http://www.explainxkcd.com/2011/08/10/p ... -strength/

Basically, once you get past the (now huge) dictionary attacks by avoiding those types of passwords, the best thing you have is password length. Padding your password with your own unique combination is a great way to add length to a password, but sitll make it easy to remember.

So D0g..1..1..1..1..1 is a great password. At one hundred trillion guesses per second, it would take 1.28 trillion centuries to crack.

I'm not saying you should use that one, but make up your own padding and add it to easier to remember passwords. It is best to have upper, lower, number, and special character but with a long enough password, it is not essential.

 

[Dayvid]

Ultimately I think a better solution would be use more multifactor systems combined with storage and interface standards to enable widespread automation. That would simultaneously give people more security while being more convenient (and in this case the two go hand in hand). I hope Ars does a survey of options relating to that in the future.

Multifactor isn't that helpful against this - it's primarily a defense against MITM/keylogger etc style threats - eg even if someone knows your password, it's not enough to login because they don't have the token/whatever. While that might still sound relevant, it depends on how the particular token works (or it's random seed etc) being a secret and remember these password leaks are *server compromises*. Two factor authenication in the one recent leak it was being employed in (blizzard) was only partly helpful - their servers were storing enough information to validate - and hence *replicate* - at least a couple of their authenticator types (and given how bad their response has been, who knows on the others).

Designing a system that works with users having 25+ different accounts and needing passwords (that are probably logged into from multiple devices including small touchscreen keyboards) that resist attack even when companies (regularly) screw up and leak their entire authentication database may not even be practical I suspect.

 

[Braumin]

Password managers are really the only solution here. You need one great password and it takes care of the rest.

No, password managers are not the solution: if someone gets the master file and able to crack it, then they will be able to access all of your passwords.

You should NOT store passwords on your local file, but store very strong random numbers and combine that with your weak password and submit those to the website. This way an attacker cannot run brute force tests without working through the site where the password would be useful.

Unfortunately the password managers are providing convenience (you do not have to type in passwords for various websites), instead they should improve security (you still have to type in your password, but that can be week and will be combined with something strong).

You obviously have no idea what you are talking about.

The day someone comes along with a crack for AES256 then I will give up LastPass. But if AES gets cracked we are in a world of hurt.

Good password managers ARE the answer. Secure it with a good long password (12-15 characters is likely enough even for any offline attack) and you will have no worries.

Please do some research on these before you shoot them down.