Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we cracked millions of Ashley Madison passwords

cynosureprime.blogspot.com

Post reply on HN
Print view View original

131–140 of 173 posts

Re: How we cracked millions of Ashley Madison passwords

#131

Post by nkassis »

JosephRedfern wrote: post #97
mtberatwork wrote: post #80

Earlier quoted context omitted.

> if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today. > If you're…

> Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today. I'm not suggesting that they'd be able to trivially crack the password (nor am I arguing that password hashing shou…

Hopefully the important data is also not stored on the system in clear text and the key to decrypt it is stored on a different server only held in a secure area of memory while the process is working.

Password have value beyond one system they can be used to impersonate the user and often they are reused on other sites like email accounts (which can be used with reset password almost everywhere to gain access to those sites).

"you could sign up for an account on the service using a known password, dump the hash of the known password, and swap out the hash of the privileged user. That way you wouldn't need to know the details of the hashing implementation."

The hash should also have a salt included (which hopefully is also not stored on the same server as the database) so hashing is salt + password =hashingfunction> hash. The salt can also be a supplemented by a user specific info (unique account id) so that hashes for one user wont' work for another

Re: How we cracked millions of Ashley Madison passwords

#133

Post by jdmichal »

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…

If you're going to signing, you may as well go all the way and just use an encryption + signing mechanism. Then you can store actual data in the token -- within reasonable transmission limits, of course.

Re: How we cracked millions of Ashley Madison passwords

#134

Post by mtberatwork »

JosephRedfern wrote: post #97
mtberatwork wrote: post #80

Earlier quoted context omitted.

> if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today. > If you're…

> Only if you are using a weak hash like MD5. The primary point of hashing a user's password is to make so that it cannot be easily cracked in the event of a DB breach/leak. Stronger hashes require much more time, energy and computing power to crack...far more than what is realistically available today. I'm not suggesting that they'd be able to trivially crack the password (nor am I arguing that password hashing shou…

Perhaps, but it would then depend on user privileges set in the database. If the application is accessing the DB as root or as a user with full admin privileges, then yes, I would say that would be a "game over" situation. On the other hand, if the DB user that is being used in the injection attack has read access to a limited set of tables, the damage may be much less severe.

> and swap out the hash of the privileged user.

True, if the initialization vectors of the hash are the same for admin and regular user accounts (for example, using the same salt for admin and normal users). You would also need write access to the DB via your injection attack.

Re: How we cracked millions of Ashley Madison passwords

#135

Post by nitrogen »

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.

Yes, in addition to migrating to pure bcrypt/scrypt at next login. I've implemented this migration strategy for two different web sites (not listed in my HN profile) with success.

Re: How we cracked millions of Ashley Madison passwords

#136

Post by redml »

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…

Hindsight is 20/20. Working on legacy software devs sometimes want to implement the proper solution on paper rather than the best one. Perhaps it was a task that the dev didn't get enough time to write something to update the passwords of a few million users. Perhaps they thought they'd come back to it in a few months and force a reset on users that hadn't switched their password yet. Who knows.

Re: How we cracked millions of Ashley Madison passwords

#137

Post by mentat »

msbarnett wrote: post #126
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?

> 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. Do…

That doesn't really have the same security properties as the original login information.

Re: How we cracked millions of Ashley Madison passwords

#138

Post by sbov »

aruggirello wrote: post #77
felixhandte wrote: post #67

Earlier quoted context omitted.

They have the db dumps, so yes, they know the usernames. And they used a rainbow table[1] to break the md5 hashes, which is a lot cheaper than brute-forcing. [1] ( https://en.wikipedia.org/wiki/Rainbow_table )

Then would replacing md5() with hash_hmac('sha256' [= or whatever ], strtolower($username) [= data ], strtolower($password) [= key ] ) help against such an attack? If I understand correctly, this would have ruled out rainbow tables. Edit: clarified. BTW hash_hmac is built-in with PHP >= 5.1.2.

The problem isn't just rainbow tables. Md5 is a fast algorithm. Sha256 isn't much slower than md5. You want anything auth related hashed using a slow algorithm - speed is your enemy.

That's why bcrypt and the like are popular, because you can adjust how long it will take to calculate.

Re: How we cracked millions of Ashley Madison passwords

#139

Post by joesmo »

Someone1234 wrote: post #108
rnovak wrote: post #102

Earlier quoted context omitted.

Well, lets be fair here. Saying "Don't roll your own encryption" doesn't specify "maths" or "applied crypto" (which incidentally covers security/auth mechanisms). It's a bad idea to roll your own versions of either the maths part or the applied part, so I don't think the GP was inaccurate in his statement.

I agree with what you're saying, I just don't understand how it applies here. Tons of people have created broken versions of popular encryption schemes. They go to Wikipedia, get the AES algorithm, and then implement it. That implementation turns out to be flawed, and by "rolling their own encryption" even if it is based on a very secure one, like AES, they have been incorrectly encrypting content. But that doesn't a…

"Don't roll your own authentication" seems to me to be even more pertinent advice than "Don't roll your own encryption" as it's a much more common mistake that I see at almost every single place I've worked at. I think it's not a common phrase because authentication is really not that hard and most engineers think they can do it properly. My experience, at least, shows that they can't. Everything from plaintext passwords to symmetric encryption happens and it happens at companies one would expect would implement some security. I've seen CTOs and Engineering Directors argue against changing the plaintext passwords till they were blue in the face and I just gave up. Obviously, our industry has done little to educate people on this issue and in almost every single major breach, it's easy to see how this was a key factor in making the leak worse by leaking the actual passwords or their improperly stored "hashes" (because in some cases they're not even hashes).

Re: How we cracked millions of Ashley Madison passwords

#140

Post by sbov »

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.

Not so complicated if you plan for this sort of stuff ahead of time, or even at migration time. You can prepend your hashed fields with the algorithm used, and have a library that automatically handles them.

This also makes generating test data easier, as our library has a "plaintext" hash type, so we can just insert "$plaintext$password" rather than having to run a hash on the password.

Post reply on HN