Why you should take hacked sites’ password assurances with a grain of salt

Beware of e-mails that play down the ease of cracking your leaked passcode.

Reputation.com, a service that helps people and companies manage negative search results, has suffered a security breach that has exposed user names, e-mail and physical addresses, and in some cases, password data.

In an e-mail sent to users on Tuesday, officials with the Redwood City, California-based company said the passwords were "highly encrypted ('salted' and 'hashed')," a highly vague description that can mean different things to different people. "Although it was highly unlikely that these passwords could ever be decrypted, we immediately changed the password of every user to prevent any possible unauthorized account access," the e-mail added unconvincingly.

It's unfortunate that companies make such assurances, because they may give users a false sense of security. As Ars has been reporting for nine months, gains in cracking techniques means the average password has never been weaker, allowing attackers to decipher even long passwords with numbers, letters, and symbols in them. Even Ars' own Nate Anderson—a self-described newbie to password cracking—was able to crack more than 45 percent of a 17,000-hash list using software and dictionaries he downloaded online.

Jeremi Gosney, a password cracking expert with Stricture Consulting Group recently explained in an Ars forum post that it's highly unusual for a leaked password list to go uncracked, as suggested by the Reputation.com e-mail.

"It definitely depends on the specific leak we're talking about, but generally speaking, your average security expert/penetration tester/casual password cracker is probably only going to be able to recover at most 50-60% of passwords in any given leak," he wrote. "Seasoned password crackers will likely recover 70-75%; and truly exceptional password crackers will recover 80% or more."

Adding cryptographic salt to passwords is crucial to the safe storage of passwords because it forces password cracking programs to guess the plaintext for each individual hash, rather than guessing passwords for thousands or millions of hashes all at once. (Yes, it also thwarts rainbow-table attacks, but no one uses this method anymore.) But it's easy to overstate the benefits of salting. It in no way slows down the cracking of a single hash, so if an attacker locates the hash belonging to a particular high-value Reputation.com user, the measure does nothing to thwart the cracking of that hash. The security value of salting alone only slows down cracking of large lists by a multiple of the number of unique salts, so that value decreases with each hash that is decoded.

A far more meaningful security measure is the type of algorithm that's used to convert plaintext passwords into cryptographic hashes. If the company used SHA1, SHA3, MD5, or any number of other "fast" hashes, it's extremely likely that at least some of the leaked password data has already been cracked. If, on the other hand, the company used bcrypt, scrypt, PBKDF2 or another "slow" algorithm specifically designed to hash passwords, the chances are significantly lower. Reputation.com makes no mention of the algorithm it used, so users should presume the worst. Anyone who used their Reputation.com password to protect one or more accounts on other sites should change those passcodes immediately. Passwords should be randomly generated by a password-manager, contain a minimum length of 11 characters, and include numbers, letters, and symbols. They should also be unique to each site.

Promoted Comments

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

I'm a developer too, and I've just recently done exactly this migration on a production project - from an older, less secure password hashing method to bcrypt. It wasn't that hard - I kept the old password hashes and algorithm, and use them as a "fall-back" for users who haven't logged in since we switched over. As soon as they log in, it re-hashes their password (same as a "create new password field"), and they're transparently using bcrypt. After a few months or perhaps up to a year, I'll drop the old algorithm, and the remaining mostly-dormant users will just have to request a new password.

We're about 3 months in now, and it's working extremely smoothly. This project is fairly seasonal, so after the summer, it'll be safe to assume that people who haven't logged in since we switched are most likely to stay dormant, so I'll drop the remaining old passwords.

Here is the message these sites should use if they lose their password database to hackers.

Dear user we're requiring that you change your password immediately! If your password is used for any other accounts GO CHANGE IT NOW! Do not use the same password for multiple websites as it can come back to bite you in the ass.

It's absurd that companies are allowed to blow off a problem serious as a database loss. People need to realize crackers are going to fucking destroy that list and fast. The fact that the company downplays it only says one thing "hey crackers you are all a bunch of morons and you'll never crack these passwords"

They need to start treating the makers of cracking software and the crackers with respect because they're very fucking smart and to pretend they're not is very dangerous on your part.

PSA to anyone using XKCD-style-passphrase generators: these usually have relatively low entropy. For instance, the number one Google results for XKCD passphrase generator is Preshing.com. This has an entropy of 44 bits because it only uses 1949 words (log2(1949^4)). Whereas a randomly generated 7 character password has an entropy of 46 bits (log2(95^7)). The number two result has an even smaller word list of only 1426.

The "correct horse battery staple" is a good foundational idea, but...

...it can be improved by adding numbers and punctuation. The easiest way to do this is integrate them into such a passphrase, e.g. "correct horse's 42 battery staples", but...

...the more consistent the phrase is with the rules of grammar, the smaller the keyspace needed to search in order to crack it, so if you like the XKCD method, it'd be better to use a phrase that's memorable but not grammatically correct (as there are more ways to violate the grammar of a natural language than to not violate it), e.g. "correctly Mr. Ed's staples 42 battery"...

...and you can see, once again, we're entering a strength vs memorizability tradeoff, but if this is your one password used to unlock a password manager, you're good. Assuming you can type that ê on all devices.

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

I'm also a developer. You're wrong.

See drosboro's post for one implementation/explanation of an easy password hashing migration. (I came in to post basically the same solution)

As to management and cost, you're also wrong. Your service is not using a working password solution, it's using a dangerously broken one which happens to "function" in allowing users to log in but at the same time does not function in terms of security. Many similar services have been compromised recently and media is paying more attention (references): a breach with the current system could be very costly, far more so than simply fixing it now (dig up some data on similar situations). Fixing it now can also be leveraged into PR and marketing related to the service's increased security, which will lead to enough new sales among security conscious customers to cover the cost of the upgrades (go dig up some data). [Password data can be very valuable in the wrong hands, and as in all information security it's the value of the data which signifies: it's important to consider this when evaluating appropriate data protection costs (can cite numerous infosec "gurus" if you need some "expert punchiness" on this).] That's the gist of the argument you (well, your department head) should be taking to "management."

The problem isn't often that management isn't doing the right thing: it's more often that you're not presenting the issue to them properly.

I see no one evers mention Dashlane, is it bad? I've been using it for the past month and find it great.

For curiosity's sake I just look at their white paper. They're at least smart enough to use the PBKDF2 key derivation technique, but they use it with the SHA1 hashing algorithm.

LastPass and (to my knowledge) KeePass both use PBKDF2 but they combine it with the SHA512 (SHA2) hashing algorithm. I'm a little shocked a password manager would use SHA1 even when combined with PBKDF2.

I'm not sure of the source of your concern over SHA1. Is it because it's "broken," or because it's computationally faster?

If the former, it's mostly a non-issue. Password security is only marginally affected by weak collision resistance. There are two kinds of attacks on crypto hashes: collision attacks and preimage attacks. A password cracker would need a preimage attack. SHA1 has been found vulnerable to collision attacks, but there's no known practical or near practical preimage attack. Such attacks are much, much more difficult. Furthermore, the SHA2 family is almost broken in regards to collision attacks, as SHA1 is, so for collision resistance we should be using the new SHA3.

If the concern is about speed, it looks like SHA1 is about 50% faster than Sha512, and I suppose that could add up to quite a bit of time over 10000 iterations.

Bit of a devil's advocate position here, but as near as I can tell, password length/complexity and hashing algorithms are both irrelevant. The only thing that matters is password sharing.

I assume that, if a website is hacked to the extent that the password database is stolen, then 1. All of your data from that site is already in the attacker's hands, and 2. Your password will eventually be cracked, no matter how complex it is or what clever hash algorithm the site is using. Given that, why bother making passwords harder to crack? What are you protecting, except for data that the attacker probably already has? I also assume that the site owners are aware that they are hacked and can fix the holes and make everybody change their passwords. As long as that password is not used anywhere else, it doesn't matter.

I just created a new account to post here. I used LastPass to create a new complex password for it, just like every other site I use. I don't care at all if Ars stores all of their passwords in plaintext and puts their database on a public server because that password won't do anybody any good.

Then you should be ok with giving me your online banking password.

No? Why not?

Because I could transfer all your money to my account, right?

So, while what you wrote about a cracker already having your data is true, if they don't have your password they can't perform ongoing actions that require your password.

And while any password is theoretically crackable , slowing down the cracker gives the site and its users time to fix the problem, change passwords, etc.

1. While most services store a hash of the Master Password on their server, in order to authenticate their users, we do not. That is because the Master Password is only used to derive the encryption key for the user’s personal data. You can find more details in our Security White Paper available at https://www.dashlane.com/en/security2. Hence, a brute force attack on the hashes of the Master Password is impossible because we do not store the Master Password anywhere. The only thing stored on our servers and on the user’s devices are the AES256 ciphered data, which is more difficult to brute force than a password hash3. When comparing PBKDF2 SHA1 and PBKDF2 SHA 256, you need to also take into account the number of iterations used to derivate the key. Dashlane uses 10,000 iterations including on mobile devices. At that level of iteration, and with a complex enough Master Password which we enforce, our level of security is in line with the best practices to date. Competing products that rely on SHA 256 often have to use a much lower number of iterations, in particular on mobile devices. See http://www.insidepro.com/eng/egb.shtml for more info.4. Theoretical collusion attacks does not concern SHA1 when used with PBKDF2 with many iterations to derivate a key to cipher data with AES 256

Thanks for the response. I think the major selling point they have is that the master password is never stored locally nor remotely and never transmitted over a network. I don't know how that works but I'm not feeling very secured now. So I will start looking for other alternatives.

I see no one evers mention Dashlane, is it bad? I've been using it for the past month and find it great.

For curiosity's sake I just look at their white paper. They're at least smart enough to use the PBKDF2 key derivation technique, but they use it with the SHA1 hashing algorithm.

LastPass and (to my knowledge) KeePass both use PBKDF2 but they combine it with the SHA512 (SHA2) hashing algorithm. I'm a little shocked a password manager would use SHA1 even when combined with PBKDF2.

The issue isn't with a password manager using SHA1 with PBKDF2. It's with websites that are vague about how they store your password. If someone got hold of the Dashlane's database it may or may not be simple to crack it open and have all your logins. I'm not concerned with them getting access to this information because (IMO) it's less likely to happen than a website I visit being targeted by password thieves.

I'm just one person on the Internet with a log in to 100 sites. One site on the Internet has a login for a million people. Bigger fish.

It would not be "simple" to get the passwords in Dashlane's database even if someone managed to get offline access to it. Using PBKDF2 can make cracking hashed passwords extremely difficult even with SHA1.

However, comparatively speaking, it would be much easier for crackers to get access to Dashlane's password hashes than it would be for say LastPass' password hashes. Both would be long and difficult to crack, but when compared between other password managers, I'm quite disappointed that Dashlane went with SHA1. I'm already content with LastPass and have been the last 3 years, but still, I expect the best security measures possible out of a password manager and Dashlane is lacking. I mean, unless I'm missing something on their website, it doesn't even look like they support Two-Factor authentication.

"It would be much easier for crackers to get access to Dashlane's password hashes, etc..." --> My understanding of their white paper is that they don't have password hashes to begin with. Also, I'm not an expert but after some googling I came across this stack overflow thread: http://stackoverflow.com/questions/4938 ... -in-pbkdf2What do you guys think?

102 Reader Comments

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

Other frameworks should outright copy the Django 1.4+ approach to passwords, it makes it very simple to upgrade passwords to new algorithms and work-factor/iterations:

At this point, I'm fairly certain someone has either hacked LastPass to download their database, is actively working on it...

They had a security breach about..oh, 4 years ago or more, I want to say. Maybe it was 3?

Nothing has ever come of that though. If anyone ever did get the database, they haven't said anything. More than likely what happened is that they got access to a server and it was taken offline before they could do anything.

Even if they did get a hold of a password database though, what exactly do you think they could do with it? You and I will be long dead and buried before they even get close to even cracking the passwords that are hashed with the "weaker" master passwords.

From what you can read there it was probably nothing. They were very much on top of it and took extra precautions to protect their users. Most companies would not have known about the anomaly, much less have said anything to their users. LastPass's transparency in this case won me their trust. But I don't think this was a true hack.

The article mentions using a password manager, which I've seen suggested in a few places. Is there an Ars recommendation that I could try? It's probably about time I got genuinely serious with my passwords.

I came here to post that exact question. I know that I should switch to a password manager and will be doing that in the next week or so but not sure what the best ones out there would be.

Also nothing to do with the topic but I find it amusing that I can set 2 factor auth up for Facebook but not for my bank. Makes me wonder if there is a technical reason for that that I am not aware of.

This is the best comparison of passwords managers I was able to find. I imagine Ars will probably go even further in depth as to the actual security measures they use (like Steve Gibson did for LastPass several years ago) but this should provide a nice aggregate of information for you to choose whichever one suits your needs best.

With all the hacked sites recently, I've been thinking long and hard about using LastPass, along with a random password generator, as a way to increase the security of my accounts. Anybody have any experience with this approach? Anything I need to know, possible unintended consequences, etc?

EDIT: And now I see that this has been already asked and answered. That'll learn me for only reading page 1 of the comments.

In this communities experience, what is your favorite password manager and why? As I stated earlier I micromanage all of my passwords and it is tiresome to say the least!

LastPass. It's on all major platforms. It uses a Trust No One model (i.e., they cannot reset your master password because they do not know it.) You can set the number of iterations for the encryption of your password vault file. You can use two-factor auth, like Google Authenticator or Yubikey. You can use it offline, if need be. It even allows you to share a password with someone else, without the other person ever knowing the password itself (it gets added the the other person's encrypted vault.)

Oh, and it will also scan your passwords, and warn you when you have duplicates.

Edit to add: They also have a service to warn you if your username has been exposed in a known breach.

Honestly,, I see the world going more towards the OAuth2 or Federated STS model. I'd rather just login with my Google or Microsoft account then going through the hassle of passwords, and emails. Also why code it yourself especially when these security services are free.

Screw that! I hate it when websites do that. Why should I have to link everything in the world back into my Gmail account?

Most of the web links back to your gmail account whether or not you decide to login with it or not.

The problem is single factor authentication...any thing that relies solely on a single password can be cracked eventually. Multi-factor auth, if done right, can be nigh uncrackable. You not only have to crack the password, but somehow you have to crack the second factor as well. That second factor could be anything from a securid, biometric input or private/public key pair.

Thats not to say multi-factor can't be cracked, but it is exponentially more difficult.

Two-factor authentication almost always necessitates a separate physical device. Aside from biometrics, you need some additional trusted device, be that a phone, a rolling token, a flash drive with a private key, whatever. Why not ditch the password all together and just use that private key? If you really want something two-factor, you could always put a password on that private key. A couple thousand bit private key will never be cracked (for a reasonable number of decades), so all you have to worry about is the loss of that physical key, which is the same problem you're going to have with any other two-factor authentication.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

I'm a developer too, and I've just recently done exactly this migration on a production project - from an older, less secure password hashing method to bcrypt. It wasn't that hard - I kept the old password hashes and algorithm, and use them as a "fall-back" for users who haven't logged in since we switched over. As soon as they log in, it re-hashes their password (same as a "create new password field"), and they're transparently using bcrypt. After a few months or perhaps up to a year, I'll drop the old algorithm, and the remaining mostly-dormant users will just have to request a new password.

We're about 3 months in now, and it's working extremely smoothly. This project is fairly seasonal, so after the summer, it'll be safe to assume that people who haven't logged in since we switched are most likely to stay dormant, so I'll drop the remaining old passwords.

The problem is single factor authentication...any thing that relies solely on a single password can be cracked eventually. Multi-factor auth, if done right, can be nigh uncrackable. You not only have to crack the password, but somehow you have to crack the second factor as well. That second factor could be anything from a securid, biometric input or private/public key pair.

Thats not to say multi-factor can't be cracked, but it is exponentially more difficult.

Two-factor authentication almost always necessitates a separate physical device. Aside from biometrics, you need some additional trusted device, be that a phone, a rolling token, a flash drive with a private key, whatever. Why not ditch the password all together and just use that private key? If you really want something two-factor, you could always put a password on that private key. A couple thousand bit private key will never be cracked (for a reasonable number of decades), so all you have to worry about is the loss of that physical key, which is the same problem you're going to have with any other two-factor authentication.

You seem to be missing the point of two-factor authentication. It's supposed to be something you know and something you have. Removing either one from the equation means it's no longer two-factor authentication.

PSA to anyone using XKCD-style-passphrase generators: these usually have relatively low entropy. For instance, the number one Google results for XKCD passphrase generator is Preshing.com. This has an entropy of 44 bits because it only uses 1949 words (log2(1949^4)). Whereas a randomly generated 7 character password has an entropy of 46 bits (log2(95^7)). The number two result has an even smaller word list of only 1426.

The article mentions using a password manager, which I've seen suggested in a few places. Is there an Ars recommendation that I could try? It's probably about time I got genuinely serious with my passwords.

I've been using Roboform for a few years, I never see it mentioned in other people's lists of available software.

Here is the message these sites should use if they lose their password database to hackers.

Dear user we're requiring that you change your password immediately! If your password is used for any other accounts GO CHANGE IT NOW! Do not use the same password for multiple websites as it can come back to bite you in the ass.

It's absurd that companies are allowed to blow off a problem serious as a database loss. People need to realize crackers are going to fucking destroy that list and fast. The fact that the company downplays it only says one thing "hey crackers you are all a bunch of morons and you'll never crack these passwords"

They need to start treating the makers of cracking software and the crackers with respect because they're very fucking smart and to pretend they're not is very dangerous on your part.

I just started using lastpass after Living Social's big fail. I'm 95% sold on it. Just by installing it, it found all my web browsers' saved passwords and loaded them right into its database. I went to all those sites where I used the same username and password (Bad Dog!) as Living Social and immediately had LastPass generate new random passwords for them.

If you are trying to log into a site on a new device that doesn't have LastPass, and you don't want to or can't install LastPass, just go to lastpass.com. Log in with your master username/password, and you can see/copy any of your randomly-generated passwords.

So of course the security of your entire life is entirely dependent on the security of lastpass.com, but I guess I trust them more than your average, run-of-the-mill website. I guess.

These articles make it seem as though the advances in password cracking are increasing faster than password storing. Is this true? And if so, that must mean that the current system is unsustainable.

I don't think it's true that password cracking is outstripping secure password storage. bcrypt, scrypt, and PBKDF2 allow developers to specify the number of hashing iterations a password is given. As long as developers are incrementing those iterations over time, things should be fine. I'd be interested in knowing if password experts agree.

...and as long as those hashes aren't greatly optimized over their current implementations, as we've seen with some other hashes recently. But even then, if the hash is optimized to run 3x faster, yes, increase the number of iterations 3x and you're good.

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

In Python, passlib handles this for you and includes transparent upgrading. Create a CryptContext which allows old, crappy hashes for matching, but only your chosen algo for storage; when a user logs in correctly, if their stored hash is outdated, it's transparently upgraded with no need for interaction at all.

PSA to anyone using XKCD-style-passphrase generators: these usually have relatively low entropy. For instance, the number one Google results for XKCD passphrase generator is Preshing.com. This has an entropy of 44 bits because it only uses 1949 words (log2(1949^4)). Whereas a randomly generated 7 character password has an entropy of 46 bits (log2(95^7)). The number two result has an even smaller word list of only 1426.

The "correct horse battery staple" is a good foundational idea, but...

...it can be improved by adding numbers and punctuation. The easiest way to do this is integrate them into such a passphrase, e.g. "correct horse's 42 battery staples", but...

...the more consistent the phrase is with the rules of grammar, the smaller the keyspace needed to search in order to crack it, so if you like the XKCD method, it'd be better to use a phrase that's memorable but not grammatically correct (as there are more ways to violate the grammar of a natural language than to not violate it), e.g. "correctly Mr. Ed's staples 42 battery"...

...and you can see, once again, we're entering a strength vs memorizability tradeoff, but if this is your one password used to unlock a password manager, you're good. Assuming you can type that ê on all devices.

If you're looking for a password manager, you've already won. Congratulations. Which one you choose is really going to be a matter of personal preference, for convenience, free or paid, cloud-based or not, etc. They're all good.

I like KeePass. It's open source, completely separated from the cloud, though you can use services like DropBox to sync it, and does everything I need it to do including a whole lot of offline stuff that I have no doubt the other managers can also replicate, but since it does its job well, I haven't felt the need to change.

Does it integrate with your browser as seemlessly as others? I've heard no, but then I like granular control, and would prefer to manually manipulate my password entries and other secret goodies my kb dbs (multiple, I have 2 layers of security there too) hold. That's just me though, many others seem to enjoy just logging on once with LassPass or whatever and not having to worry about passwords again for their session, at least based on hearsay. I don't even bother with various plugins or extensions that supposedly make it easier to use, like Keefox for FireFox, but they do exist, and I guess they make your lives easier at the cost of aforementioned granular control that OCD people like me enjoy (and to my paranoid mind, each layer of integration is just one more attack vector I'd have to worry about, and I'll gladly sacrifice some convenience for even perceived security).

So of course the security of your entire life is entirely dependent on the security of lastpass.com, but I guess I trust them more than your average, run-of-the-mill website. I guess.

Not exactly. It's dependent on the security of your master passphrase + their code. They mostly just host blobs of encrypted data and write/maintain software to access it. Depending on your settings, all your encrypted passwords may be cached in your browser, smartphone, etc, in encrypted form - the strength of the algorithm is the secondary thing that matters, the security of your passphrase is the primary thing that matters. If it's keylogged or beaten out of you, well.

The article mentions using a password manager, which I've seen suggested in a few places. Is there an Ars recommendation that I could try? It's probably about time I got genuinely serious with my passwords.

There are several robust password managers on the market, including 1Password, LastPass, Keepass and PasswordSafe. Stay tuned for articles in the next few weeks that will provide more tips for securing your passwords.

Keepass is awesome. I use it on my:

Win 7 desktopWin 7 laptopiPadLinux laptop

It's so simple to both create new passwords and enter in existing ones.

A suggestion for the articles: can you (collectively) go into how to best secure the password manager itself? I have a system, but I doubt it's ideal.

This is the best comparison of passwords managers I was able to find. I imagine Ars will probably go even further in depth as to the actual security measures they use (like Steve Gibson did for LastPass several years ago) but this should provide a nice aggregate of information for you to choose whichever one suits your needs best.

I like Gibson and listen to his podcasts, but I was disappointed w/his LassPass coverage since he mostly just focused on why he liked it (fine and dandy if that's all you're evaluating), but only gave cursory mention of the competitors, esp. KeePass. I was really hoping he'd break down their pros & cons more, but once he finds a technology he likes, like this new VPN hosting service that TWIT is pushing (and they're also sponsors), he doesn't really examine alternatives a whole lot. Having said that, I stand by my "they're all good" approach in that the use of *any* competent password manager is a pure win. The rest is just personal preference.

Even though I actually agree w/that lifehacker article, I still would take anything from their, or any Gawker site, w/a grain of salt. I'm very much looking forward to an Ars breakdown of the various managers.

I'm a developer too, and I've just recently done exactly this migration on a production project - from an older, less secure password hashing method to bcrypt. It wasn't that hard - I kept the old password hashes and algorithm, and use them as a "fall-back" for users who haven't logged in since we switched over. As soon as they log in, it re-hashes their password (same as a "create new password field"), and they're transparently using bcrypt. After a few months or perhaps up to a year, I'll drop the old algorithm, and the remaining mostly-dormant users will just have to request a new password.

I just bcrypted the old SHA-1 hashed passwords. This way I could rewrite all passwords in a day with a simple batch job. I figured keeping the SHA-1 in there wouldn't lower the security.

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

I'm also a developer. You're wrong.

See drosboro's post for one implementation/explanation of an easy password hashing migration. (I came in to post basically the same solution)

As to management and cost, you're also wrong. Your service is not using a working password solution, it's using a dangerously broken one which happens to "function" in allowing users to log in but at the same time does not function in terms of security. Many similar services have been compromised recently and media is paying more attention (references): a breach with the current system could be very costly, far more so than simply fixing it now (dig up some data on similar situations). Fixing it now can also be leveraged into PR and marketing related to the service's increased security, which will lead to enough new sales among security conscious customers to cover the cost of the upgrades (go dig up some data). [Password data can be very valuable in the wrong hands, and as in all information security it's the value of the data which signifies: it's important to consider this when evaluating appropriate data protection costs (can cite numerous infosec "gurus" if you need some "expert punchiness" on this).] That's the gist of the argument you (well, your department head) should be taking to "management."

The problem isn't often that management isn't doing the right thing: it's more often that you're not presenting the issue to them properly.

I see no one evers mention Dashlane, is it bad? I've been using it for the past month and find it great.

For curiosity's sake I just look at their white paper. They're at least smart enough to use the PBKDF2 key derivation technique, but they use it with the SHA1 hashing algorithm.

LastPass and (to my knowledge) KeePass both use PBKDF2 but they combine it with the SHA512 (SHA2) hashing algorithm. I'm a little shocked a password manager would use SHA1 even when combined with PBKDF2.

I'm not sure of the source of your concern over SHA1. Is it because it's "broken," or because it's computationally faster?

If the former, it's mostly a non-issue. Password security is only marginally affected by weak collision resistance. There are two kinds of attacks on crypto hashes: collision attacks and preimage attacks. A password cracker would need a preimage attack. SHA1 has been found vulnerable to collision attacks, but there's no known practical or near practical preimage attack. Such attacks are much, much more difficult. Furthermore, the SHA2 family is almost broken in regards to collision attacks, as SHA1 is, so for collision resistance we should be using the new SHA3.

If the concern is about speed, it looks like SHA1 is about 50% faster than Sha512, and I suppose that could add up to quite a bit of time over 10000 iterations.

The problem is single factor authentication...any thing that relies solely on a single password can be cracked eventually. Multi-factor auth, if done right, can be nigh uncrackable. You not only have to crack the password, but somehow you have to crack the second factor as well. That second factor could be anything from a securid, biometric input or private/public key pair.

Thats not to say multi-factor can't be cracked, but it is exponentially more difficult.

Two-factor authentication almost always necessitates a separate physical device. Aside from biometrics, you need some additional trusted device, be that a phone, a rolling token, a flash drive with a private key, whatever. Why not ditch the password all together and just use that private key? If you really want something two-factor, you could always put a password on that private key. A couple thousand bit private key will never be cracked (for a reasonable number of decades), so all you have to worry about is the loss of that physical key, which is the same problem you're going to have with any other two-factor authentication.

You seem to be missing the point of two-factor authentication. It's supposed to be something you know and something you have. Removing either one from the equation means it's no longer two-factor authentication.

I really am missing the point, as I don't see the point. No one is going to crack a decently long key in a useful time frame, so it is by all rights secure. The only concern is of that key being physically stolen, and if you want, you can always password lock that key to get you that second factor you're looking for. My point is, if we're even bothering with password managers at this point, why not just go whole hog and make private keys the standard?

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

I'm also a developer. You're wrong.

The problem isn't often that management isn't doing the right thing: it's more often that you're not presenting the issue to them properly.

Bit of a devil's advocate position here, but as near as I can tell, password length/complexity and hashing algorithms are both irrelevant. The only thing that matters is password sharing.

I assume that, if a website is hacked to the extent that the password database is stolen, then 1. All of your data from that site is already in the attacker's hands, and 2. Your password will eventually be cracked, no matter how complex it is or what clever hash algorithm the site is using. Given that, why bother making passwords harder to crack? What are you protecting, except for data that the attacker probably already has? I also assume that the site owners are aware that they are hacked and can fix the holes and make everybody change their passwords. As long as that password is not used anywhere else, it doesn't matter.

I just created a new account to post here. I used LastPass to create a new complex password for it, just like every other site I use. I don't care at all if Ars stores all of their passwords in plaintext and puts their database on a public server because that password won't do anybody any good.

And once you've chosen an encryption scheme it's very difficult to change it to something better without forcing a password change on users when they login

Actually, it's pretty easy. There are several approaches that can be done behind the scenes without users knowing it happened. One way I recently used; make what ever your new hash scheme is accept as input the output of your old scheme. Ie, if you used to md5(password), now you would bcrypt(md5(password)). Attempt authentication with the new scheme. If it fails, attempt with the old scheme. If that succeeds, hash the old stored password using the new scheme and store that as the hashed password. Next login, it will match against bcrypt(md5(password))

Bit of a devil's advocate position here, but as near as I can tell, password length/complexity and hashing algorithms are both irrelevant. The only thing that matters is password sharing.

I assume that, if a website is hacked to the extent that the password database is stolen, then 1. All of your data from that site is already in the attacker's hands, and 2. Your password will eventually be cracked, no matter how complex it is or what clever hash algorithm the site is using. Given that, why bother making passwords harder to crack?

It's not about using a 'clever algorithm', it's about slowing down the attacker. Slow him down enough and the stolen encrypted passwords won't be cracked. An algorithm that's 10.000 times slower can't be solved by using a slightly faster cpu. It's the difference between needing a few days to crack the passwords, or a few decades.

Bit of a devil's advocate position here, but as near as I can tell, password length/complexity and hashing algorithms are both irrelevant. The only thing that matters is password sharing.

I assume that, if a website is hacked to the extent that the password database is stolen, then 1. All of your data from that site is already in the attacker's hands, and 2. Your password will eventually be cracked, no matter how complex it is or what clever hash algorithm the site is using. Given that, why bother making passwords harder to crack? What are you protecting, except for data that the attacker probably already has? I also assume that the site owners are aware that they are hacked and can fix the holes and make everybody change their passwords. As long as that password is not used anywhere else, it doesn't matter.

I just created a new account to post here. I used LastPass to create a new complex password for it, just like every other site I use. I don't care at all if Ars stores all of their passwords in plaintext and puts their database on a public server because that password won't do anybody any good.

Then you should be ok with giving me your online banking password.

No? Why not?

Because I could transfer all your money to my account, right?

So, while what you wrote about a cracker already having your data is true, if they don't have your password they can't perform ongoing actions that require your password.

And while any password is theoretically crackable , slowing down the cracker gives the site and its users time to fix the problem, change passwords, etc.

The problem is single factor authentication...any thing that relies solely on a single password can be cracked eventually. Multi-factor auth, if done right, can be nigh uncrackable. You not only have to crack the password, but somehow you have to crack the second factor as well. That second factor could be anything from a securid, biometric input or private/public key pair.

Thats not to say multi-factor can't be cracked, but it is exponentially more difficult.

Two-factor authentication almost always necessitates a separate physical device. Aside from biometrics, you need some additional trusted device, be that a phone, a rolling token, a flash drive with a private key, whatever. Why not ditch the password all together and just use that private key? If you really want something two-factor, you could always put a password on that private key. A couple thousand bit private key will never be cracked (for a reasonable number of decades), so all you have to worry about is the loss of that physical key, which is the same problem you're going to have with any other two-factor authentication.

You seem to be missing the point of two-factor authentication. It's supposed to be something you know and something you have. Removing either one from the equation means it's no longer two-factor authentication.

I really am missing the point, as I don't see the point. No one is going to crack a decently long key in a useful time frame, so it is by all rights secure. The only concern is of that key being physically stolen, and if you want, you can always password lock that key to get you that second factor you're looking for. My point is, if we're even bothering with password managers at this point, why not just go whole hog and make private keys the standard?

Social engineering, sir. I could give you my password to LastPass and you still wouldn't be able to get in as you dont' have my Yubikey. Conversely, if you stole my Yubikey, it would do you no good as you don't have my password.

Perhaps you weren't online during that whole security fiasco with that writer from Wired who got his digital life shit smacked because of social engineering. Didn't matter how good his passwords were because of the way they conned the companies behind his accounts.

Where-as if he had enabled Two-factor authentication, he never would have had a story to write about in the first place.

2. Your password will eventually be cracked, no matter how complex it is or what clever hash algorithm the site is using.

Wrong. If you used a long, randomized and complicated password, even a weak algorithm can prove difficult to nigh impossible to crack. Combined with a good password and a good algorithm - the chances are it'll never be cracked in your lifetime, much less before you get a chance to reset your password on the website. And if you follow smart password practices, you don't use that singular password on any other website so it's a complete non-factor as far as any security implications for you are concerned.

Just posting this here cause its about passwords and not sure what other forum it would fit into. So I've been looking into KeePass and just had a question (can't just try it since I'm at work now) when I install KeePass is there a way for it to recognize all of my current passwords that are saved into chrome or will I have to go and do that manually. I know that I will have to go change them all manually just want to know if it will find them all.

I see no one evers mention Dashlane, is it bad? I've been using it for the past month and find it great.

For curiosity's sake I just look at their white paper. They're at least smart enough to use the PBKDF2 key derivation technique, but they use it with the SHA1 hashing algorithm.

LastPass and (to my knowledge) KeePass both use PBKDF2 but they combine it with the SHA512 (SHA2) hashing algorithm. I'm a little shocked a password manager would use SHA1 even when combined with PBKDF2.

I'm not sure of the source of your concern over SHA1. Is it because it's "broken," or because it's computationally faster?

If the former, it's mostly a non-issue. Password security is only marginally affected by weak collision resistance. There are two kinds of attacks on crypto hashes: collision attacks and preimage attacks. A password cracker would need a preimage attack. SHA1 has been found vulnerable to collision attacks, but there's no known practical or near practical preimage attack. Such attacks are much, much more difficult. Furthermore, the SHA2 family is almost broken in regards to collision attacks, as SHA1 is, so for collision resistance we should be using the new SHA3.

If the concern is about speed, it looks like SHA1 is about 50% faster than Sha512, and I suppose that could add up to quite a bit of time over 10000 iterations.

Because it's faster. Even when being combined with PBKDF2 to increase its computation, it's still far faster from a computational standpoint than SHA512.

I agree they should be moving to SHA3 at some point (hopefully sooner rather than later) but given the fact you're relying on these password managers with your digital livelihood, they should be using the best of the best or at least damn near close. At this point - and as it has been for quite a while now - that is not SHA1.

I assume that, if a website is hacked to the extent that the password database is stolen, then 1. All of your data from that site is already in the attacker's hands, and 2. Your password will eventually be cracked, no matter how complex it is or what clever hash algorithm the site is using.

Your point 2 is incorrect. Your password may never be cracked, and it depends exactly on both how complex it is, and what clever hash algorithms are in place. You may want to read up on how only certain %s of leaked hashes get cracked, and depending on the level of sophistication of the cracker. From this very article:

Quote:

"It definitely depends on the specific leak we're talking about, but generally speaking, your average security expert/penetration tester/casual password cracker is probably only going to be able to recover at most 50-60% of passwords in any given leak," he wrote. "Seasoned password crackers will likely recover 70-75%; and truly exceptional password crackers will recover 80% or more."

Also, even if they all eventually do get cracked (which, again, it likely won't), it takes time, as in days or weeks for the more complicated hashes, and news of leaks spread relatively (we hope) quickly. Which then gives you time to change all your passwords. If you're using a simple password, it may be cracked faster than another entry in the database which gives the cracker all weekend (many attacks occur on Fridays, just so they have 2 more potential days before IT & media can react) to see what other accounts that cracked password might work on.

The rest of your arguments basically fail since your main premise is misinformed.

The article mentions using a password manager, which I've seen suggested in a few places. Is there an Ars recommendation that I could try? It's probably about time I got genuinely serious with my passwords.

As others have said, KeePass (or KeePassX on other operating systems) is a safe start. If you're using Firefox as your browser then the Keefox add-on can provide an extra autofill capability. I find it can recognize about 80% of login fields.

BTW Keepass does about 60,000 rounds of encryption to open the database, just out of the box. You can and should increase this to a larger number to slow initial unlocking and increase security. Click on tab File -> Database settings -> Security.

The other part of using a password manager is to be sure you have backups of the database — lots of backups, recent backups, offsite backups.

As a developer, it's truly bizarre to see so many sites not using a password-safe hash like PBKDF2 or brcypt/scrypt. Libraries exist for every popular language so doing it right is just as easy as doing it wrong.

Basically I think it's easy to start a new project that way, but it's hard to migrate an existing project to a better password storage solution, especially since management won't understand why you have to spend time 'fixing something that isn't broken'.

Having just completed a project where we migrated to PBKDF2, I'd have to say you are DEAD WRONG. It's this simple:

1. Select PBKDF2 Library2. Add fields for pwhash and hashiterations to your authentication database3. Change authentication routine to feed the user record, hashiterations, and user input of password to PBKDF24. Trigger password conversion to PBKDF2 either by sending an email blast through your existing password-reset system (after zeroing out the existing pw's), OR by converting from plain text, if you were that dumb in the past.

Also, management understands all too well the risks of a data breach and the legally-mandated public disclosures. If they don't spend 10 minutes googling and sending them links. And seriously, if you are on such a project, you should be sending every link to a new article about data breaches, large and small, to your management.

The article mentions using a password manager, which I've seen suggested in a few places. Is there an Ars recommendation that I could try? It's probably about time I got genuinely serious with my passwords.

I've recently started diving into this myself. Starting with LastPass. I think I'm going to move towards something like KeePass, though. The difference being the latter I can carry around a USB drive (and not need my phone) for those 'oh shit' moments when I need to login somewhere.

The article mentions using a password manager, which I've seen suggested in a few places. Is there an Ars recommendation that I could try? It's probably about time I got genuinely serious with my passwords.

I was wondering this as well. I attempted to convert to KeePass 2.x last week, and it was....cumbersome and didn't work the seamless way it sounded it would. Plus I could never really get it to generate passwords and input them anywhere, or even create a text file with them....

I would certainly love to have 25-character ridiculously hard passwords everywhere, but from Firefox to Keepass and back, or even just integrating them, was a tad more difficult than I was used to. But maybe I jumped the gun? Also, what of portable versions of each of the managers?

Also, and I know this has probably been asked somewhere in this (and other) comments; What does Ars use for password hashing and salting, I wonder?

Speaking of which, is it possible we could have a cryptography expert come in and write a couple articles going over the different hashing and encryption schemes in use? I've been trying to acquaint myself with them, but there is a lot of seemingly advanced math involved in a lot of them.....:-)