How we cracked millions of Ashley Madison passwords • Hacker News Board

Re: How we cracked millions of Ashley Madison passwords

#121

Post by hardwaresofton » Thu, Sep 10, 2015, 3:30 PM UTC

pygy_ wrote: post #81

hardwaresofton wrote: post #68

Earlier quoted context omitted.

They didn't really roll their own encryption right? They rolled their own session login stuff, used it for some sort of login-key (what I assume they passed with server sessions). Why they would do that instead of a simple session ID I will probably never know. Maybe they did it so they could have independent backends (instead of having to share session keys across load balanced api servers).

> Maybe they did it so they could have independent backends (instead of having to share session keys across load balanced api servers). Since at some point the loginkey was based on the unencrypted password that means that they either had to store the PW in clear (and fetch them from the DB) or generate the key at account creation and fetch it from the DB anyway. A good strategy to check the token validity without re…

Yeah, I'm familiar, which is why I was surprised they had to deal with this at all -- most frameworks handle sessions like this for you automatically...

Re: How we cracked millions of Ashley Madison passwords

#122

Post by KMag » Thu, Sep 10, 2015, 3:37 PM UTC

dfc wrote: post #79

KMag wrote: post #36

Earlier quoted context omitted.

There are a significant number of ways paswords/password hashes stored in a DB might be revealed that wouldn't result in write access to the DB. Off the top of my head: (1) Timing attacks against string comparison (in the hash cases, this usually also implies a guessable salt) (2) Misconfigured servers showing exceptions/debug info to users, coupled with sensitive information in debug messages, coupled with a remotel…

Your comment is killing the layout of this page. Can you please fix the formatting of your message? HN does not support arbitrary markdown. And even if it did indenting by four spaces would yield pre-formatting not an ordered list.

Sorry, it's too late to edit now. I'll read up on HN formatting for future note.

Re: How we cracked millions of Ashley Madison passwords

#123

Post by grandalf » Thu, Sep 10, 2015, 3:38 PM UTC

> This meant that we could crack accounts created prior to this date with simple salted MD5.

This means that there was a decision not to force previously created accounts to update their passwords to make their accounts more secure.

Contrast this with the big Evernote vulnerability where all users were required to reset their passwords.

Re: How we cracked millions of Ashley Madison passwords

#124

Post by syncsynchalt » Thu, Sep 10, 2015, 4:00 PM UTC

heynk wrote: post #104

djrogers wrote: post #100

The real lesson here is that when you fix your mistakes, go back and fix your mistakes retroactively! AM used an insecure login token at one point, and 3 years ago they fixed it. They switched from an MD5 of lower(pass)+username to an MD5 of the bcrypted pass+username, which is no longer reversible. Apparently they never updated all of the previous login tokens though, so anyone who had created an account before the…

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

No, you can re-hash the original hash you have, and add an additional check at login for new-hash(original-hash(password)).

Re: How we cracked millions of Ashley Madison passwords

#125

Post by TallGuyShort » Thu, Sep 10, 2015, 4:02 PM UTC

encoderer wrote: post #112

heynk wrote: post #104

Earlier quoted context omitted.

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

No, you just take the original MD5 of lower(pass)+username and run that thru your new bcrypt. You will have a more complicated authentication process but it's worth it.

The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes.

edit: I guess most people only start out with short passwords, thus limiting the possible entropy anyway...

Re: How we cracked millions of Ashley Madison passwords

#126

Post by msbarnett » Thu, Sep 10, 2015, 4:03 PM UTC

heynk wrote: post #104

djrogers wrote: post #100

The real lesson here is that when you fix your mistakes, go back and fix your mistakes retroactively! AM used an insecure login token at one point, and 3 years ago they fixed it. They switched from an MD5 of lower(pass)+username to an MD5 of the bcrypted pass+username, which is no longer reversible. Apparently they never updated all of the previous login tokens though, so anyone who had created an account before the…

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

> I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

No. Well, I mean, it's common to do that, but it's a bad idea and it's not necessary to keep all of those vulnerable hashes around.

Say you have a bunch of MD5 password hashes stored, and you want to upgrade your password hashing to BCrypt. Don't wait for the user to login and rehash their plain text password.

Instead, Bcrypt all the MD5s. The authentication mechanism is now BCrypt(MD5(plaintext)) == stored_bcrypt. Upgrade them to straight bcrypt on login.

Re: How we cracked millions of Ashley Madison passwords

#127

Post by msbarnett » Thu, Sep 10, 2015, 4:07 PM UTC

TallGuyShort wrote: post #125

encoderer wrote: post #112

Earlier quoted context omitted.

No, you just take the original MD5 of lower(pass)+username and run that thru your new bcrypt. You will have a more complicated authentication process but it's worth it.

The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes. edit: I guess most people only start out with short passwords, thus limiting the possible entropy anyway...

> The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes.

The entropy isn't the significant problem with MD5. The problem is how damn fast you can perform 2 billion MD5 hashes on modern machines.

Re: How we cracked millions of Ashley Madison passwords

#128

Post by adevine » Thu, Sep 10, 2015, 4:08 PM UTC

TallGuyShort wrote: post #125

encoderer wrote: post #112

Earlier quoted context omitted.

No, you just take the original MD5 of lower(pass)+username and run that thru your new bcrypt. You will have a more complicated authentication process but it's worth it.

The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes. edit: I guess most people only start out with short passwords, thus limiting the possible entropy anyway...

Entropy is not really the issue here. For a dictionary attack with a non-reversible hash, what matters is how computationally intensive it is to generate the hash. MD5 hashes can be generated very quickly, while bcrypt hashes take much, much longer to generate.

Re: How we cracked millions of Ashley Madison passwords

#129

Post by knodi123 » Thu, Sep 10, 2015, 4:13 PM UTC

heynk wrote: post #104

djrogers wrote: post #100

The real lesson here is that when you fix your mistakes, go back and fix your mistakes retroactively! AM used an insecure login token at one point, and 3 years ago they fixed it. They switched from an MD5 of lower(pass)+username to an MD5 of the bcrypted pass+username, which is no longer reversible. Apparently they never updated all of the previous login tokens though, so anyone who had created an account before the…

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

> that's the only time you have the PW in plain text

Well, if the issue is that your hash is crackable.... ;-)

Re: How we cracked millions of Ashley Madison passwords

#130

Post by bradleyjg » Thu, Sep 10, 2015, 4:17 PM UTC

thedz wrote: post #107

heynk wrote: post #104

Earlier quoted context omitted.

I thought the standard way of migrating your PW hashing function was that you could only do it during a login, because that's the only time you have the PW in plain text. No?

This wasn't the PW hashing fucntion. The new method hashes using the bcrypt of the password, which they do have.

Bingo. All they had to do is delete all the login tokens. Users with what would have otherwise been a valid cookie would have had to re-log in, but that's a minor inconvenience that's expected to happen from time to time.