Amongst the hyperbole and horror of the Ashley Madison hack there is a bit of good news. OK, perhaps not exactly good news, but some more bad news that might have happened and didn’t.
There isn’t a trove of millions of cracked Ashley Madison passwords.
If a username and password can be stolen from one site there’s a good chance it will work on lots of others too because many users habitually reuse their passwords. It’s a bad habit that gives successful attackers a free hit at dozens of other websites and spreads the misery a lot more widely.
That hasn’t happened to Ashley Madison users, which means that while the scope of the attack might be devastating, it is in some important respects contained.
And that’s because the passwords held by Ashley Madison were stored correctly, something that’s laudable enough that it’s worth pointing out.
In fact, strictly speaking, Ashley Madison didn’t store any passwords at all. What the company kept in its database were hashes created by passing users’ passwords through a key derivation function (in this case bcrypt).
A key derivation function takes a password and transforms it through the magic of cryptography in to a hash—a string of binary data of a fixed length, typically from 160 to 256 bits (20 to 32 bytes) long.
💡 Learn more: Salting, hashing and key derivation ►
That’s good, because passwords can be turned in to hashes, but proper cryptographic hashes are “one way functions”, so you can’t turned them back into passwords.
The authenticity of a user’s password can be determined when they log in by passing it through the key derivation function and seeing if the resulting hash matches a hash stored when the password was first created.
That way, an authentication server only ever needs a user’s password very briefly in memory, and never needs to save it on disk, even temporarily.
So, the only way to crack hashed passwords stored to guess: try password after password and see if the right hash turns up.
Password cracking programs do that automatically: they generate a sequence of possible passwords, put each one through the same key generation function their victim used, and see if the resulting hash is in the stolen database.
Most guesses fail, so password crackers are equipped to make billions of guesses.
Hash derivation functions like bcrypt, scrypt and PBKDF2 are designed to make the cracking process harder by requiring lots more computational resources than just a single hash calculation, forcing crackers to take longer to make each guess.
A single user will barely notice the extra time it takes to log in, but a password cracker whose aim is to generate as many hashes as possible in the shortest possible time can be left with little to show for the effort.
An effect ably demonstrated by Dean Pierce, a blogger who decided to have some fun cracking Ashley Madison hashes.
The optimistic Mr Pierce set about cracking the first 6 million hashes (from a total of 36 million) from the adultery hookup site’s stolen database.
Using oclHashcat running on a $1,500 bitcoin mining rig for 123 hours he managed to test 156 hashes per second:
Yes, that's right, 156 hashes per second. To someone who's used to cracking md5 passwords, this looks pretty disappointing, but it's bcrypt, so I'll take what I can get.
After five days and three hours work he stopped. He had cracked just 0.07% of the hashes, revealing a little over 4,000 passwords having tested about 70 million guesses.
That might seem a lot of guesses but it’s not.
Good passwords, created according to the kind of proper password advice that we advocate, can stand up to 100 trillion guesses or more.
What Pierce uncovered were the very dregs at the bottom of the barrel.
Password crackers are carefully programmed to try what they think are the most likely guesses first, so that 123456 and PASSWORD will be tried long before WXZQAN and 34DF%%R9.
In other words, the first passwords to be revealed are inevitably the easiest to guess, so what Pierce found was a collection of truly awful passwords.
The top 20 passwords he recovered are listed below. For anyone used to seeing lists of cracked passwords, or the annual list of the worst passwords in the world, there are no surprises.
| Password | Occurrences (out of 4007) |
|---|---|
| 123456 | 202 |
| password | 105 |
| 12345 | 99 |
| qwerty | 32 |
| 12345678 | 31 |
| ashley | 28 |
| baseball | 27 |
| abc123 | 27 |
| 696969 | 23 |
| 111111 | 21 |
| football | 20 |
| f***you | 20 |
| madison | 20 |
| a**hole | 19 |
| superman | 19 |
| f***me | 19 |
| hockey | 19 |
| 123456789 | 19 |
| hunter | 18 |
| harley | 18 |
The terrible nature of these passwords demonstrates neatly that password security is a partnership between the users who think up the passwords and the organisations that store them.
If Ashley Madison hadn’t stored their passwords correctly then it wouldn’t matter if users had chosen strong passwords or not, millions of good passwords could have been compromised.
When passwords are stored correctly, however, as they were in this case, they’re unbelievably hard to crack, even if the data theft is an inside job.
Unless the passwords are really bad.
If your password is PASSWORD or 123456, or a word you’d find in a dictionary with a few L3TT3R5 5W4PP3D 0UT for numbers then it’s toast, no matter how well it’s stored.
(I’m not going to let Ashley Madison completely off the hook, of course: the company stored its users’ passwords well but it didn’t stop users from choosing truly bad ones, and it didn’t stop the hashes from being stolen.)
Crackers tend to unearth a lot of bad passwords very quickly, but the law of diminishing returns soon kicks in.
In 2012 Naked Security’s own Paul Ducklin spent a few hours cracking passwords from the Philips data breach (passwords that were not as well stored as Ashley Madison’s).
He was able to crack far more passwords than Pierce with less powerful equipment, because the hashes weren’t computationally expensive to crack, but the results clearly show how the total number of passwords cracked quicky levels out.
25% of the Philips passwords lasted just 3 seconds.
Then it took 50 minutes to get the next 25% of of the passwords, and a full hour after that to crack a further 3%.
Had he continued, then the time between cracking each new password would have increased, and the curve would have looked flatter and flatter.
Before long he’d have been faced with hour-long gaps between successful password cracks, then days, then weeks…
Unfortunately, as Ashley Madison’s users found out, you can’t tell if the companies you deal with are going to keep all your data safe, just your password or none of it at all.
What you can do is be circumspect about who you give real data to, and keep your side of the password bargain by giving companies a strong and unique password to store:
(Enjoy this video? Check out more on the SophosLabs YouTube channel.)
Bob Smith (@DingleBob)
What about the security/password reset data entries, if there were any, such as “What is your Mother’s maiden name” and so on. Were those answers hashed also? Probably not.
Incredibly Strong Unique passwords are completely useless they are paired with Strong Unique USERNAMES also. There are companies I deal with regularly that not only enforce password expiration, but they also enforce usernames to expire as well.
Cyber_Guy_001
Yeah. The whole “email as your username” thing always gets me. If the user and password can both be changed and both be made “Strong”/Unique, you have a much more secure system AND less chance of a repeat hack if breached.
People are less inclined to abandon an email address but, they will alter login credentials if prompted in a security message.
Mark Stockley
If your password is stored correctly and strong—fourteen characters or more ought to be able to withstand trillions of guesses—then the incremental improvement in actual real-world security you get from a similarly unique and well hashed username doesn’t seem like much to me. Passwords are supposed to be secret and usernames aren’t, so just choose a longer password.
You don’t need crazy-strong security to defeat attackers looking for a second bite of the cherry either, just different passwords.
Cyber_Guy_001
In an ideal world… yes. But, we know that most people don’t do this. We know that people “recycle” their passwords. We know that a large portion of passwords are easily cracked.
Giving away one piece of the puzzle, because the other piece should be difficult to guess, is not the right way of doing things. Granted, people would reuse/recycle usernames, just as they do with passwords. At least it isn’t up front in giving away a portion of the login credentials.
It is much more difficult to guess a username and a password, than just a password. If both are weak, the status quo isn’t really impacted. If both are mildly strong, it increases greatly in the realm of security. If both are strong, you have an even higher level of protection. Simply, if it takes three seconds to break a simple PW, it would take nine seconds (or more) to break a simple username + PW combo. From two hours to four hours for a weak combo. etc…
If you know my username has to be John_Doe @ someemail .com, the only thing you need to crack is my password. If you don’t know my username, you have to generate usernames and a matching password. Why shrug off added security because people should be doing “X”, when when know that many people just don’t do it?
Mark Stockley
It seems to me that user names are likely to be far more guessable than passwords and the very best you can hope for is the same poor choices as you get with passwords. So yes, two poor passwords are probably better than one but is that the best security we can offer?
I agree with you that it’s a fact that users choose poor passwords and simply asking them not to hasn’t made any difference. I think this is down to companies and IT departments passing the buck.
Companies need to take responsibility by rejecting bad passwords, storing good ones properly and using two factors, e.g.
1) Reject any password on a list of (say 10,000) known bad passwords taken from live data breaches like RockYou and Adobe.
2) Use the zxcvbn password strength meter and reject any password it doesn’t class as strong.
3) …or take a leaf out of WordPress’s book and issue users with strong passwords that they can choose to override (assuming their choice can meet the first two criteria).
…users are now armed with strong passwords…
4) Use rate limiting (3 strikes and you’re out) to defend against online password guessing attacks.
5) Store passwords hashed with scrypt or similar to defend against offline password guessing attacks.
6) Use two factor authentication.
Mark Stockley
Password reset questions have issues beyond how they are stored.
https://nakedsecurity.sophos.com/2015/05/26/yup-we-really-are-terrible-at-those-password-recovery-questions/
R. Dale Barrow
What are these magic cryptographic ‘bites’ you refer to?
Paul Ducklin
Errr, it was supposed to be “bits” :-)
Fixed, thanks.
roy jones jr
I would have to go find the old article, but I recall mentioning of usernames/passwords in the authentication and security on the business side.
Given that the outside world can’t muster being able to routinely do passwords correctly, an alternative should be considered. Even if incremental, it would be a small step to something better.
Andrew Ludgate
To add to the discussion about secure passwords/usernames/recovery questions, a while back I discovered something else: one of my ultra secure 27 character passphrases had the unfortunate honour of, when hashed via bcrypt, hashing to the same value as a password that shows up in dictionary attacks.
I haven’t run the math on the odds of that happening, but I suspect it’s not as remote a possibility as it seems it should be, especially if you really are using a different password everywhere. And since all sorts of different hashing methods are used, it’s not trivial to pick a password whose hash is known to be secure.