Why LivingSocial’s 50-million password breach is graver than you may think

Articles like this make me wonder about my own hashing methods. Does one-thousand or so iterations of SHA512 with salting between each iteration sound sufficient to all of you smart people on Ars? Or should I just make sure bcrypt is installed and go with that?

But I urge you, please don't try to roll your own algorithm unless you are highly experienced with this. You may make some silly design mistake that you are not experienced enough to catch, and that may prove to have devastating consequences if your database is ever compromised. There are existing solutions for iterated SHA512 if that's what you want to use.

sha512crypt is built into PHP, and is available through the native crypt(3) interface on Linux/Unix with most all other popular languages.

bcrypt is also a good option, and there are also plenty of libraries for bcrypt out there as well.

Thank you for the information. I'll go back and review crypt(). I think that I was having a problem using it with the version of PHP that I am stuck with, which is probably a good sign that I should upgrade that as well.

Thank you for the information. I'll go back and review crypt(). I think that I was having a problem using it with the version of PHP that I am stuck with, which is probably a good sign that I should upgrade that as well.

If you continue to struggle with it shoot me an email, we'll get it worked out in your code.

I'm not a UNIX administrator. Is it normal to put logins (in this case emails), salts, and password hashes all in the same file?

Can someone explain to me the pros of that? Instead, just store one hash. Hash the email attempt with some scheme, concatenate that with the password attempt and check that against a list of known valid hashes. I understand everyone needs their own directory so hash the result of the above one more time and use that as their directory.

It seems if my password table from above (hashes of (hashed email + password)) were to ever leak it would be seriously difficult to unravel anything on it. If you had dictionary of emails to work from and knew which hash schemes were used at each step it would still be possible I guess.

They've already got the password lists from Linkdin, WorldofWarcraft, and several other sets of million+ users' passwords. And since most of the logins now use your email address as half your login, they'll try your login at all the other sites they think you might access.

Another good reason to always use aliases instead of your real e-mail. This works best if you have your own domain(s). Make a unique alias for each site and service you need to register to, perhaps even using password generation rules to create the alias (within the range of symbols acceptable for e-mail addresses). For extra protection you could have a domain with only aliases, pointing to your real account(s) on a different domain.

If you happen to get any spam to these aliases you know there's been a breach, too

I'm not a UNIX administrator. Is it normal to put logins (in this case emails), salts, and password hashes all in the same file?

Well, replace file with database, and you're near the truth. However, some sites have a site salt found in a configuration file/script, and per-user salts in the database. Of course, there isn't much protection if the breach is on the system/web server software, since many sites have the DB and web server in the same place.

A recommended way to protect a login mechanism is to not use a privileged database account for the login. When verifying passwords, use an account which only has read access to the bare minimum if tables. Once logged in, elevate privileges by opening a new DB connection with a different DB user. The ultra-paranoid could have a third layer only accessible after authenticating as an admin

That should at least limit damage to the database if some injections slip through. No write access, no rewriting the user table, and if they get in, no real privileges. Slow down the hackers, use fail2ban or similar solutions, and use complicated passwords with unusual usernames.

SHA1 is an extremely bad choice? SHA2 exists only since a very few years and SHA3 is brand new. Some rhetoric.

You misunderstand. SHA1, SHA2 and SHA3 are for creating hashes really fast. For storing passwords you want something that will take as long a time to crack as practical for your login system. You want a slow hashing algorithm for this purpose (e.g. bcrypt, scrypt, or PBKDF2).

1. Your own password.2. The password protection methods a company uses.3. The companies anti social engineering guidelines.

If any one of those fail it's possible you may loose a lot of personal information.

Your own password is the first line that is why it's very important to use long passwords with special characters. "Not leet speak"

The companies protection methods should be strong in this day and age waiting to loose 50 million passwords before you upgrade is not how you do it. In this case you should refer back to one and ask yourself is my password good? If it's |\/|1KeL0vesS3x you're probably in trouble "if a database is stolen it's vital that you change EVERY PASSWORD THAT IS REMOTELY CLOSE" no ifs, ands, or buts about it!

If they get access to one of your accounts and it happens to be your recovery account for everything you're fucked.

The companies anti social engineering guidelines is extremely important. What good is a password if you can just call up and pretend to be such and such and reset it to your hearts desire? People are stupid and gullible when it comes to social engineering which makes it very dangerous to you if they have enough privileges to reset your account password or even get into your account.

A password should be protected to the max at all three levels because even a password with a million characters can be completely worthless against social engineering.

I add use a different non-trivial password for each site and do not store the passwords with an online service. If you wish store the encrypted file on a USB stick. I recommend using a password manager set to use all the characters on your keyboard (US keyboard 96 characters) and a length of 32+ (the longer the better) to generate random strings of gibberish. Unique passwords for each site limits the damage to only that site. Long, gibberish passwords buys time to reset the password and may be for practical purposes "uncrackable", e.g. the time required is so long that it is likely the log in will have been changed or deleted, or you are dead. Remember these break ins have a limited life of probably a few months. So if it takes 5 years to crack your password you likely have plenty of time to change the password and it is likely your password will be one of the ones not cracked.

...A short 5 character alpha-numerical salt will still only mean 36^5, or approx 60 million extra checks per password, which probably adds a couple of seconds of cracking time per password just using an i7 core processor, not even considering a multi-GPU setup....

Ignoring the other problems in this analysis of how well salts work, if you add an extra 5 characters to a password it doesn't add 60 million extra checks, it increases the number of checks by a factor of 60 million. If your password was previously two characters then adding five more characters increases the size of the password space from 36^2 to 36^7. That is 60 million times as many passwords, or about 78 billion additional passwords to check. Exponential growth. Ask for it by name.

...A short 5 character alpha-numerical salt will still only mean 36^5, or approx 60 million extra checks per password, which probably adds a couple of seconds of cracking time per password just using an i7 core processor, not even considering a multi-GPU setup....

Ignoring the other problems in this analysis of how well salts work, if you add an extra 5 characters to a password it doesn't add 60 million extra checks, it increases the number of checks by a factor of 60 million. If your password was previously two characters then adding five more characters increases the size of the password space from 36^2 to 36^7. That is 60 million times as many passwords, or about 78 billion additional passwords to check. Exponential growth. Ask for it by name.

Which is why password length > than password complexity by a wide margin. As long as you're not using a dictionary word...

Also. I don't know that I believe an i7 can generate even 60 million hashes in seconds, even if we are talking sha1. Maybe i'm being ignorent on that point though.

...A short 5 character alpha-numerical salt will still only mean 36^5, or approx 60 million extra checks per password, which probably adds a couple of seconds of cracking time per password just using an i7 core processor, not even considering a multi-GPU setup....

Ignoring the other problems in this analysis of how well salts work, if you add an extra 5 characters to a password it doesn't add 60 million extra checks, it increases the number of checks by a factor of 60 million. If your password was previously two characters then adding five more characters increases the size of the password space from 36^2 to 36^7. That is 60 million times as many passwords, or about 78 billion additional passwords to check. Exponential growth. Ask for it by name.

60 million extra checks per password (check), that's the same as increasing by a factor of 60 million. Good catch though, sometimes I skip typing a word that needs to be there.

...A short 5 character alpha-numerical salt will still only mean 36^5, or approx 60 million extra checks per password, which probably adds a couple of seconds of cracking time per password just using an i7 core processor, not even considering a multi-GPU setup....

Ignoring the other problems in this analysis of how well salts work, if you add an extra 5 characters to a password it doesn't add 60 million extra checks, it increases the number of checks by a factor of 60 million. If your password was previously two characters then adding five more characters increases the size of the password space from 36^2 to 36^7. That is 60 million times as many passwords, or about 78 billion additional passwords to check. Exponential growth. Ask for it by name.

Which is why password length > than password complexity by a wide margin. As long as you're not using a dictionary word...

Also. I don't know that I believe an i7 can generate even 60 million hashes in seconds, even if we are talking sha1. Maybe i'm being ignorent on that point though.

Ya, you're right. First Google result says 277 milliseconds for 10000 hashes, which works out to about 27 minutes for 60M. I guess that's why you need GPUs.

Is there a reason not to use both a shared secret and a salt? If you kept the shared secret secret enough some of these breaches would result in no stolen passwords. For example, the shared secret could be kept in RAM only and loaded by the program from another server.

Imagine a Google news release:

Due to a freak electrical storm we lost our shared secret in RAM server. All your Google data is lost. Please start from scratch. Hopefully this will not happen again.

PS: Our bad, we are sorry.

Long story short, anything is possible, but you can not add irreversible failure modes to your business critical applications either. At a Google scale, you cannot even add a 30 minute trip for an engineer to drive in and type the secret back into RAM.

...A short 5 character alpha-numerical salt will still only mean 36^5, or approx 60 million extra checks per password, which probably adds a couple of seconds of cracking time per password just using an i7 core processor, not even considering a multi-GPU setup....

Ignoring the other problems in this analysis of how well salts work, if you add an extra 5 characters to a password it doesn't add 60 million extra checks, it increases the number of checks by a factor of 60 million. If your password was previously two characters then adding five more characters increases the size of the password space from 36^2 to 36^7. That is 60 million times as many passwords, or about 78 billion additional passwords to check. Exponential growth. Ask for it by name.

This analysis may be theoretically correct, but it doesn't necessarily have much practical use in the real world of password cracking. That's because this analysis assumes a cracker is going to brute-force your password hash. That almost never happens. The vast majority of password cracking is done with word lists and rule sets. This frequently leads to the cracking of 10-, 15-, even 20-character passwords, at least when they're not randomly generated. Bigger is not automatically better.

Which is why password length > than password complexity by a wide margin. As long as you're not using a dictionary word...

I did the math on this a while back, and adding four characters to a password was almost universally a better return than adding complexity, including mixing case and adding symbols. Only three if you're only adding a numeral.

My current password system is 13 characters, dynamically generated based on the site, unique to each site, contains nothing that is dictionary based, and something I can remember. I plan to upgrade that sometime soon to 20 characters. Hopefully I don't run into more sites that aren't capable of accepting appropriately strong passwords. I already run into trouble just using a single common symbol.

At least I don't have a bank that allows only 6 characters. I feel for all of you out there that bank with those people; I'd refuse to have an online account were that the case.

Passwords should be randomly generated by a password-manager, contain a minimum length of 11 characters, and include numbers, letters, and symbols.

That minimum of 11 characters is okay for today, but don't forget Moore's Law. If you don't intend to change your password for a year or two, go for something larger - 12 to 15 random characters.

And yes, you should change your passwords every six months. Like the average person will be happy to do.

I don't know which average people you've ever met, but I've never seen this password policy being met with anything besides groaning and sticky notes on monitors in a business. It's an absolutely horrible idea, especially when multiplied over the number of passwords people have to deal with today. It also tends to decrease complexity of passwords to the simplest thing that can meet whatever the password requirements are (8 letters, with symbols and alphanumeric? $<kid's name><birthdate> it is. Then cycle through kids and birthdays), rather than encouraging complexity.

The reality is that a password breach isn't likely to happen with someone spending 8 months trying to crack a single password without anyone knowing that the passwords were stolen in the first place. If something happens, a laptop is lost, a server is hacked, your policy should be to immediately change all passwords and keep complexity and the security system high, like in this scenario. Changing your password every 6 months with LivingSocial would have given you exactly zero additional protection.

Changing your password every 6 months with LivingSocial would have given you exactly zero additional protection.

This. Requiring passwords be changed constantly just leads to reduced security of the passwords in question while adding no actual benefit. Unless the user is otherwise insecure, which isn't going to be improved with password changes that aren't based on events as opposed to some arbitrary time limit.

Which is why password length > than password complexity by a wide margin. As long as you're not using a dictionary word...

I did the math on this a while back, and adding four characters to a password was almost universally a better return than adding complexity, including mixing case and adding symbols. Only three if you're only adding a numeral.

My current password system is 13 characters, dynamically generated based on the site, unique to each site, contains nothing that is dictionary based, and something I can remember. I plan to upgrade that sometime soon to 20 characters. Hopefully I don't run into more sites that aren't capable of accepting appropriately strong passwords. I already run into trouble just using a single common symbol.

At least I don't have a bank that allows only 6 characters. I feel for all of you out there that bank with those people; I'd refuse to have an online account were that the case.

No. But all else being equal, bigger will give better results than other forms of increased complexity.

Of course, the best option is to go with length as well as complexity, and push the ROI of cracking your password well into the negative.

Your password doesn't have to be uncrackable, it just has to be difficult to the point where it becomes unprofitable.

I think you are looking at the probability of guessing a random string and saying the longer the "keyspace" the lower the probability that it will be guessed in a meaningful time frame. That's true of course.

But the story author said that password crackers are not doing it by guessing random strings, they are using very large wordlists (and rules). In that case, complexity is very important. They're probably not going to crack a 20 character random string but they might be able to crack a 24 character password of "passwordpasswordpassword", if it's on their wordlist.

Perhaps this is not the ideal place to ask this - but I'm fuzzy on the security risk and my wife is Living Social member. She, however, does not have a Living Social account, she connected via Facebook. What happens in this instance?

My assumption is that all credentials are on Facebook's end of the deal. Is that correct, or is some tantalizing piece of useful data in the Living Social database as well?

Passwords should be randomly generated by a password-manager, contain a minimum length of 11 characters, and include numbers, letters, and symbols.

That minimum of 11 characters is okay for today, but don't forget Moore's Law. If you don't intend to change your password for a year or two, go for something larger - 12 to 15 random characters.

And yes, you should change your passwords every six months. Like the average person will be happy to do.

I don't know which average people you've ever met, but I've never seen this password policy being met with anything besides groaning and sticky notes on monitors in a business. It's an absolutely horrible idea, especially when multiplied over the number of passwords people have to deal with today. It also tends to decrease complexity of passwords to the simplest thing that can meet whatever the password requirements are (8 letters, with symbols and alphanumeric? $<kid's name><birthdate> it is. Then cycle through kids and birthdays), rather than encouraging complexity.

The reality is that a password breach isn't likely to happen with someone spending 8 months trying to crack a single password without anyone knowing that the passwords were stolen in the first place. If something happens, a laptop is lost, a server is hacked, your policy should be to immediately change all passwords and keep complexity and the security system high, like in this scenario. Changing your password every 6 months with LivingSocial would have given you exactly zero additional protection.

This...

Security consciousness is great, but if it seriously affects usability, then, there is a problem. People may know it's good to do, but will find it a hassle. If given other (less secure) options, they will use them.

Where there is no excuse is on the administrative side. People are paid to be security conscious, and should do their due diligence in the effort to keep things safe.

Glitch: Take a look at Dan's earlier article on using a password guessing tool - and look at the current set of rules that tool comes with. Print out that ruleset.. Show it to everyone that needs a new password. obscure color, obscure animal, 4 digits.. is an easily crackable password formula. (And yes, I know that if you set the network's account rules so that the user has to change their password from 123456 to something new on their next login, and they can't reuse their last 3 passwords.. that they'll somehow still have a 6 digit password from the number row, starting at say.. 2 and going to .. 7.

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.

As an aside, I've run across plenty of sites that don't accept anything but numbers and letters. Some of the ones that don't will accept a password with symbols, giving you the illusion that it was OK, but try logging in with that password and it never works.

Symbols don't add much to the complexity. Upper+lower case letters plus numbers gives 62 possibilities; let's call that 6 bits worth. Adding the usual keyboard symbols increases that to 94 characters, or about 6.6 bit worth. So if you add just one extra character for every 10 upper+lower case plus numbers, you'll be about equal to using symbols.

Sure, they can crack 90 percent of passwords in a few days, but those are weak passwords and it will take significant resources to crack each individual password in the remaining 10 percent. It's too expensive to even attempt to crack them unless you pick out one or two targets and throw thousands/millions/billions of dollars at just that one password (depending on it's strength).

The editor suggested using PBKDF2 as a strong alternative to SHA1... PBKDF2 is usually (doesn't have to be) built around SHA1 and all it does is increase the CPU time by a few hundred or few thousand times. You can achieve the same result with any website that doesn't use PBKDF2 simply by tacking two extra characters on the end of your password.

A 6 character password with PBKDF2 is much easier to crack than an 8 character password with just SHA1

Use as strong a password as you can handle, don't use the same password everywhere, and especially apply this to important accounts such as your email address or anything related to payments (your iOS App Store password can be used to make payments for example).

Sure, they can crack 90 percent of passwords in a few days, but those are weak passwords and it will take significant resources to crack each individual password in the remaining 10 percent.

Not quite, friend. When you read about a leak being 90% cracked, you have to realize there's only a handful of really talented individuals in the whole world who are able to achieve that kind of recovery rate.

Generally speaking, only about 40-50% of the passwords recovered in large leaks like this can really be considered weak, and quite a few of those are only weak because they're passwords we've already cracked after being compromised on other sites.

The next 20-30% of passwords that we recover range from decent to really quite good. The remaining 10% that we sometimes recover are very strong passwords, and we only find them after running really clever (or hail mary) attacks for days on end. The remaining 10-15% that we fail to crack are likely those that use long, sufficiently-random passwords, or are simply more clever than us.

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; seasoned password crackers will likely recover 70-75%; and truly exceptional password crackers will recover 80% or more.

The editor suggested using PBKDF2 as a strong alternative to SHA1... PBKDF2 is usually (doesn't have to be) built around SHA1 and all it does is increase the CPU time by a few hundred or few thousand times.

Man, where to start with this one...

Just because PBKDF2 can use HMAC-SHA1 doesn't mean it's somehow essentially the same thing as using SHA1. Not by a long shot.

PBKDF2 is a strong alternative to SHA1, even if you do use PBKDF2-HMAC-SHA1, for precisely the reason you state: it allows you to tune how much work is performed for each hash. "A few thousand times" is a pretty big slow-down, especially with more and more people using 10,000 iterations or more. With a 10,000x slowdown per unique salt we're not going to recover anywhere near 40%, let alone 90%.

You can achieve the same result with any website that doesn't use PBKDF2 simply by tacking two extra characters on the end of your password. A 6 character password with PBKDF2 is much easier to crack than an 8 character password with just SHA1.

Wrong again.

I'm going to assume that you're talking about brute force and random passwords, because if you're talking about human-generated passwords that certainly not true by any means.

So let's look at how much time it would take to brute force a random 6 character password with PBKDF2-HMAC-SHA1 vs a random 8 character password with raw SHA1.

A Radeon 7970 can pull about 3,375,000,000 hashes per second with raw SHA1, and about 140,000 hashes per second with PBKDF2-HMAC-SHA1 with 10k iterations.

And again that's talking about random passwords. If we were talking about human generated passwords then adding two characters to your password certainly wouldn't help a bit with raw SHA1. The number of iterations is what kills us. It forces us to do simple yet highly targeted attacks just to get even the weakest passwords.

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; seasoned password crackers will likely recover 70-75%; and truly exceptional password crackers will recover 80% or more.

I don't think you understand what it takes to get to 90%.

90% wasn't my number, it was in the article and yes they were experts. I'm willing to bet all of those were either very short or in a dictionary.

The editor suggested using PBKDF2 as a strong alternative to SHA1... PBKDF2 is usually (doesn't have to be) built around SHA1 and all it does is increase the CPU time by a few hundred or few thousand times.

Man, where to start with this one...

Just because PBKDF2 can use HMAC-SHA1 doesn't mean it's somehow essentially the same thing as using SHA1. Not by a long shot.

PBKDF2 is a strong alternative to SHA1, even if you do use PBKDF2-HMAC-SHA1, for precisely the reason you state: it allows you to tune how much work is performed for each hash. "A few thousand times" is a pretty big slow-down, especially with more and more people using 10,000 iterations or more. With a 10,000x slowdown per unique salt we're not going to recover anywhere near 40%, let alone 90%.

My experience working in the industry is not many people use 10,000 iterations of PBKDF2. That's common among serious security firms but not a typical on-line service where speed is also a priority. Even with a $40,000 blade server, 10,000 iterations of PBKDF2 is painfully slow - slow enough users will start to complain and switch to a competitor. You can't do that kind of math in a typical http request.

You can achieve the same result with any website that doesn't use PBKDF2 simply by tacking two extra characters on the end of your password. A 6 character password with PBKDF2 is much easier to crack than an 8 character password with just SHA1.

Wrong again.

I'm going to assume that you're talking about brute force and random passwords, because if you're talking about human-generated passwords that certainly not true by any means.

So let's look at how much time it would take to brute force a random 6 character password with PBKDF2-HMAC-SHA1 vs a random 8 character password with raw SHA1.

A Radeon 7970 can pull about 3,375,000,000 hashes per second with raw SHA1, and about 140,000 hashes per second with PBKDF2-HMAC-SHA1 with 10k iterations.

And again that's talking about random passwords. If we were talking about human generated passwords then adding two characters to your password certainly wouldn't help a bit with raw SHA1. The number of iterations is what kills us. It forces us to do simple yet highly targeted attacks just to get even the weakest passwords.

Assuming 10k iterations, you're right. But I don't think many services use that many. Blackberry famously only uses *one* iteration, and the original "recommended minimum" was 1,000 iterations - in other words only 6 days to crack using your math.

But either way, an 8 character password is pretty weak by any reasonable standard and taking 23 days of processing is - in my opinion - a reasonable amount of effort for protecting someone's twitter account. If you have a database of 300,000 passwords that aren't in a dictionary, and you spend 23 days on each, it will take almost 20,000 years to crack the whole database.

If you had a 9 or 10 character password, you'd blow that 23 day figure out of the park.

I still stand by what I said originally, if you have a reasonable password then you're pretty safe with sha1. If you care about security, make it really long - 20 or so characters - it doesn't have to be random just un-guessable. A bit of effort will give you a 20 character password that is easy to remember.

I've watched too many movies where someone's fingers get chopped off or their eyeballs plucked out to ever willingly use biometrics, so I'm not inclined to go that route.

I think the solution to this is to check for a pulse as well as the pattern (fingerprint, blood vessels in eye).I also think that implementing that check should be rather trivial compared to the difficulty of creating the scanner in the first place... after all there is an iphone app that can count your pulse with the camera. Cost really shouldn't be a major barrier either, the tech is not new and has been on the market for a long time. When I got my wife her last laptop I added a finger print scanner (for the heck of it) for $25.

My experience working in the industry is not many people use 10,000 iterations of PBKDF2. That's common among serious security firms but not a typical on-line service where speed is also a priority. Even with a $40,000 blade server, 10,000 iterations of PBKDF2 is painfully slow - slow enough users will start to complain and switch to a competitor. You can't do that kind of math in a typical http request.

10,000 is the new recommended minimum.

It's also the default in SimpleCrypto.Net, which is what most people who use ASP.NET are most likely to use (and most people who use PBKDF2 for password storage are using .NET, as on Linux/Unix there are more viable options than PBKDF2 such as crypt(3) and bcrypt.)

As for the hardware requirements, see my comment on page 2 about performance testing and bcrypt. I've helped dozens of companies migrate to more secure password storage, it's not near of a challenge as most people make it out to be.

Blackberry famously only uses *one* iteration, and the original "recommended minimum" was 1,000 iterations - in other words only 6 days to crack using your math.

In that instance Blackberry was using PBKDF2 for key derivation, not for password storage. But yes, it's easy to muck up PBKDF2, which is why I personally don't usually recommend it, except for on ASP.NET.

By the way, the recommended minimum of 1000 iterations was the recommendation back in the year 2000. A lot has changed in 13 years. And yes, people thought 1000 iterations was insane at that time, much like people think 10,000 iterations is insane today.

Remember that md5crypt uses 1000 iterations as well, and was replaced back in 2007 with sha256crypt and sha512crypt, which use 5000 iterations by default. That was six years ago, and things have changed a lot since then too. Namely, GPUs.

I still stand by what I said originally, if you have a reasonable password then you're pretty safe with sha1.

We crack reasonable passwords all the time, I can assure you it's not. The problem is with password storage, not password selection. If everyone upgraded their password storage we could all go back to using the password advise we were preaching 10 years ago.

We crack reasonable passwords all the time, I can assure you it's not. The problem is with password storage, not password selection. If everyone upgraded their password storage we could all go back to using the password advise we were preaching 10 years ago.

How long does it take you to crack an 8 character password with ~95 character alphabet, and plain old SHA1? Assuming you don't know anything about what pattern it might be using and have to brute force it?

Personally I think the problem is relying on passwords for anything that requires real security. My bank for example will automatically cancel my credit card after 3 failed PIN attempts. At that point I need to bring actual ID to a branch in person to get in. Websites should be the same - at the (small business) hosting company where I work if you forget your password you have to come into our office to fix it up, we won't do it from our website or over the phone.

One thing I don't understand. How do they know what algorithm was used?

I can understand if encryption was done purely locally and then sent to the servers, because they could use various techniques to read the memory states and figure out from there. But why stop there? Why not have, say, the local machine run it through a few rounds of various methods, send the encrypted hash to the server for validation, which then runs it through another few rounds (few, in context, meaning hundreds? thousands? whatever is appropriate). I mean, even if you used crappy algorithms but used them in a long, complex sequence, they wouldn't be able to be guessed unless someone knew exactly the sequence, right? Even if the person who extracted the hash list had an account and thus had one password where they knew the input and output, they still would have to spend a lot of time basically running every possible combination of every common method for lots of potential iterations. What if you took it one step further and the actual hash that gets sent to the server in some way influences the pattern of hashes the server runs it through before storing? Even when they finally managed to break one, the same pattern of hashes wouldn't actually break a 2nd one, they'd have to start over from square 1. Think of it like salt, on crack.

Example: The hash sent to the server was AkdiT, and the server sees that hash and uses the first position 'A' to say "okay, run a Sha1," then the second position of 'k' means "Sha256." But if the next hash that comes in is kAdiT, then it runs Sha256 THEN Sha1. And you'd have to figure that out for each and every password, at least until you cracked enough to find the patterns used.

Except none of this was true.

The company used SHA1 which to anyone with any knowlege of how SHA1 works can identify a SHA1 hash.

Can you give an example of some of the strongest passwords you successfully cracked with LinkedIn?

We found several 7-16 character random passwords, but the strongest ones I suppose are passwords like these, which are 13-16 characters long and indistinguishable from random. Some of these look like they were created using that mangled passphrase method some people are using now (taking the first letter of several words, adding punctuation, etc.) Most of these were recovered by doing crazy things like randomly chopping up words and applying mangling rules, or piping the output of statsprocessor into hashcat and transforming them with randomly-generated rules. Here's some samples:

We also found several hundred keyboard walks, some more obvious than others. The less obvious ones appear random at first glance. These were all recovered using a keyboard walk generator. Here's some of the more interesting ones:

We also found several English words that were typed using foreign a IME. For example, 'سحاهىء', is a nonsense word in Arabic that was created by hitting the keys for s, p, h, i, n, x (sphinx) on their keyboard while using the Arabic IME. We found passwords like this in Arabic, Cyrillic, Greek, and Hangul.

We also cracked a ton of passphrases, which was cool. Some were found through dictionary attacks using rules to toggle case and remove and insert spaces in between words, others were found through three-way and four-way combinator attacks with and without rules. There's some examples of those on this infographic that me and Per Thorshiem made.

How long does it take you to crack an 8 character password with ~95 character alphabet, and plain old SHA1? Assuming you don't know anything about what pattern it might be using and have to brute force it?

With our GPU farm, we can brute force an 8 character random password hashed as SHA1 in about 22 hours. And we're getting ready to double the number of GPUs in our cluster in the next two weeks with AMD releasing the new 7990.

Changing your password every 6 months with LivingSocial would have given you exactly zero additional protection.

This. Requiring passwords be changed constantly just leads to reduced security of the passwords in question while adding no actual benefit. Unless the user is otherwise insecure, which isn't going to be improved with password changes that aren't based on events as opposed to some arbitrary time limit.

Although, obviously not a password expert, I don't think this is true. The benefits of changing passwords every 6 months (or better 3 months) are:

1) If someone figures out your password, then after three months they will lose access to the account (depending on how they got it in the first place this may provide some mitigation), instead of keeping access for eternity.

2) It provides a cap on the number of password guesses that an online attack can have. If you have a 3 failure or 5 failure lockout policy then it is better to limit the attacker to 2 failed attempts every 5 minutes for 3 months than 2 failed attempts every 5 minutes for 20 years.....

And it if it takes 19 years to crack the password, but you are still using that password 20 years later, then it is still worthwhile for the attacker to run the attack in the case of a targeted, high value attack....although yes you should notice those failed logins, but if you think that changing passwords is a bad security policy then you probably don't monitor failed logins.

And it if it takes 19 years to crack the password, but you are still using that password 20 years later, then it is still worthwhile for the attacker to run the attack in the case of a targeted, high value attack....although yes you should notice those failed logins, but if you think that changing passwords is a bad security policy then you probably don't monitor failed logins.

There are more reasonable options for keeping password protected accounts safe than requiring password changes just for the sake of changing passwords.

As a real-world example: The place that I work has an online account to a financial institution. Said account is needed to be accessed by half a dozen different people. Some of those people are mind-bogglingly stupid. So, because management is more interested in not having to deal with them than the security of the account, the password is something embarrassingly simple and easy to guess, generated based on the fact that the site required the company to change it every single month.

Another account is for a government site. Again, the account must be accessible by multiple people. Not only is the password written down in multiple places, but while it's less weak than the other, it's still not at all strong.

A much more sane solution would be to notify customers of failed log-in attempts between successful log ins and requiring the customer to acknowledge them, and count failed logins as starting from last logout until next successful login, while also requiring that passwords be a minimum of, say, 16 characters.

Also, anyone using the same password 20 years later (particularly considering how much changes in only 5) is likely using a keyboard walk or guessable phrase to begin with and making them change it to something else equally insecure isn't going to help them.

Can you give an example of some of the strongest passwords you successfully cracked with LinkedIn?

We found several 7-16 character random passwords, but the strongest ones I suppose are passwords like these, which are 13-16 characters long and indistinguishable from random. Some of these look like they were created using that mangled passphrase method some people are using now (taking the first letter of several words, adding punctuation, etc.) Most of these were recovered by doing crazy things like randomly chopping up words and applying mangling rules, or piping the output of statsprocessor into hashcat and transforming them with randomly-generated rules. Here's some samples:

Its really time to move away from passwords alone, randomly generated or not. Anything of any significance should require some form of 2-factor authentication. Ideally we'll move to biometrics + Passwords in the near future, but until then, using things like the two factor authenticiation that google makes available now is at least a step in the right direction.