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

Re: How we cracked millions of Ashley Madison passwords

#71

Post by CWuestefeld » Thu, Sep 10, 2015, 2:17 PM UTC

JosephRedfern wrote: post #25

sillysaurus3 wrote: post #19

Earlier quoted context omitted.

The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access. Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, the…

I get that - but in a majority of cases, isn't "juicy" information going to be held in the DB anyway? Sure, you won't be able to go in through the "front door", but if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant ad…

If an attacker somehow downloaded all my databases (because we keep data partitioned to minimize damage if one of them is compromised, as well as to better partition the application itself), then they would be able to see all of history.

But they wouldn't have the user's credit card, because that's encrypted separately with the key stored somewhere else.

And they wouldn't be able to take action on behalf of the user. That is, they couldn't place new orders as the user, or stuff like that.

Re: How we cracked millions of Ashley Madison passwords

#72

Post by ska » Thu, Sep 10, 2015, 2:20 PM UTC

paulmd wrote: post #65

gmac wrote: post #38

Earlier quoted context omitted.

If we assume every user is employing long, random, unique passwords ... then we surrender the ability to reason about the real world. Economists are fond of that kind of thing, but in IT security it's not terribly helpful. Many (most?) users employ the same password on many different sites. So now an attacker has email/password pairs that work not just on the site that was compromised, but also on Gmail, Facebook, Tw…

If you're using the passwords on multiple sites they're not unique. Not that users don't do it, but that's an invariant he stated.

Which is (part of) what makes this an unrealistic assumption.

Re: How we cracked millions of Ashley Madison passwords

#73

Post by steckerbrett » Thu, Sep 10, 2015, 2:20 PM UTC

Piskvorrr wrote: post #58

steckerbrett wrote: post #50

Earlier quoted context omitted.

If you have the computing power? If you're compromising peoples boxes you likely also have a botnet, which has practically limitless potential.

No. Given a large enough work factor, there literally aren't enough resources in the entire universe to brute-force even a single hash. "Hard to imagine" and "limitless" are very different animals. Edit: moreover, the GP has already mentioned that "[brute force] isn't a zero-cost effort in terms of time," even if you have access to humongous amounts of processing power. The point of encryption isn't to protect data f…

Limitless in the sense of applicability to tasks.

Re: How we cracked millions of Ashley Madison passwords

#74

Post by lostgame » Thu, Sep 10, 2015, 2:21 PM UTC

I used to work for these guys. Their CEO was probably the single most selfish douchebag I'd ever met.

Glad this happened to them. 'bout time Karma came a'knocking.

Oh, p.s. can confirm all women (at least 90%) are bots.

Re: How we cracked millions of Ashley Madison passwords

#75

Post by ssharp » Thu, Sep 10, 2015, 2:25 PM UTC

hellofunk wrote: post #15

asadhaider wrote: post #6

Earlier quoted context omitted.

Completely agree, Match.com does the same thing. Not so long ago a user signed up to their site using my email address (never figured out why). They were able to create an account and subscribe to the site without ever verifying the email, so for a week or so I was getting notifications sent to me without any way to unsubscribe from the email. Clicking any of the links in the email signed me in as the user and gave m…

This is frightening. Who is running the security teams at these large companies?

I find it hard to believe that they didn't know better. They were using 12 rounds of bcrypt to store the passwords, afterall. Assuming just the DB is compromised, they would likely be okay because of that. I'm not sure how often systems are so entirely pwned as to gain access to their source code repos and their entire production database. That seems like an outlier kind of attack, though I think the same thing happened with Sony.

I don't think it's fair to say that this was a security oversight, so much as it was a conscience decision to make the system have less friction for users by utilizing these login tokens.

Re: How we cracked millions of Ashley Madison passwords

#76

Post by snowwolf » Thu, Sep 10, 2015, 2:26 PM UTC

hardwaresofton wrote: post #68

snowwolf wrote: post #51

The title of the article should really be changed to "How we cracked millions of Ashley Madison passwords by bypassing their strong bcrypt hashes because they thought they were clever" but that's less clickbaity Also, never ever roll your own encryption - it will be flawed (unless you employ at least 3 crypto experts and get it peer reviewed - and even then it's probably still flawed).

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).

They generated login tokens using md5 hashes of strings that included the password. This is rolling your own encryption.

Re: How we cracked millions of Ashley Madison passwords

#77

Post by aruggirello » Thu, Sep 10, 2015, 2:30 PM UTC

felixhandte wrote: post #67

aruggirello wrote: post #59

One point is not clear to me: did the crackers know $username's already, or did they perform some kind of dictionary attack? Brute forcing both $username and $password out of millions of hashes seems a bit hard - even considering md5 trivial, not employing an hmac scheme.

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.

Re: How we cracked millions of Ashley Madison passwords

#78

Post by user_0001 » Thu, Sep 10, 2015, 2:32 PM UTC

lostcolony wrote: post #41

jand wrote: post #34

For a non-native speaker, could you please confirm or invalidate my understanding of this interesting text: 1. They attacked some login/api-token unrelated to bcrypt. 2. If I use bcrypt-validate for logins and only temporarily associate rotating, random login/api-tokens with an account, I should not be prone to such attacks. Thank you very much for your help.

1. Yes 2. Yes AM took the unencrypted password, lowercased it, and hashed it into an MD5 token that they then stored - conjecture is that it was used as a login token. That is what the article indicates was cracked, since MD5 is very weak, to get a lowercased password, then tried every permutation of capital letters on the bcrypted passwords, to get the actual passwords out. To avoid similar issues, if you generate a…

lol.

Store a strongly hashed copy of the password, but use weak hash on password for login token. oops

Re: How we cracked millions of Ashley Madison passwords

#79

Post by dfc » Thu, Sep 10, 2015, 2:32 PM UTC

KMag wrote: post #36

nilved wrote: post #17

Earlier quoted context omitted.

Chances are if they have database access, they can do that already. Many/most exploits at the application layer are made to gain access to the database.

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.

Re: How we cracked millions of Ashley Madison passwords

#80

Post by mtberatwork » Thu, Sep 10, 2015, 2:37 PM UTC

JosephRedfern wrote: post #25

sillysaurus3 wrote: post #19

Earlier quoted context omitted.

The login process looks like: User navigates to login screen and sends plaintext password to server. Server hashes the plaintext password and compares it to the hash on disk. If the hashes are equal, the server grants access. Since a user can only submit a plaintext password, not a hash, then they won't be able to log in unless they know the correct plaintext password. Even if they have a copy of the server's db, the…

I get that - but in a majority of cases, isn't "juicy" information going to be held in the DB anyway? Sure, you won't be able to go in through the "front door", but if you can get a copy of the password hash from a database dump is it not pretty much game-over anyway? If you're able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant ad…

> 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 able to perform SQL injection against the DB, would you not be able to change the password in order to gain access to the system, or grant admin privileges to your own accoun

Depends. You would need to know what hashing algos/processes, initialization vectors, etc that are in place to create the DB hashes. For example, if they are "salting" the passwords, you would also need to have the salt token on hand.