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

Re: How we cracked millions of Ashley Madison passwords

#61

Post by wtbob » Thu, Sep 10, 2015, 1:59 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…

> Given a large enough work factor, there literally aren't enough resources in the entire universe to brute-force even a single hash.

Or, given a strong-enough original password. I postulate that, until the moment I posted it, '3BgZhZcGPcHswmfic79jgjsfqyMKW1Rh1rkFjagJC090V2tljd9Zy2vpYJw944HG' would never have been brute-forced, even with an extremely low work factor (in fact, it wouldn't have been brute-forced even without bcrypt, scrypt or PBKDF2: even were it just stored as a simple SHA2-512(pw) (i.e., baafbe64d25f27d4b7b2965f9abf43cf25acd8fc6021798a90253f33b3071e9 fd145eaccd555290913c8679fd4acf949f05243ac1089548abbab0e0ed77e63 31), no computer on earth, nor all the computers which ever have been or ever will be, would have brute-forced it (unless there's something we don't know about SHA2, or about computing).

Lesson? Always use high-quality random passwords. For a 128-bit security level, with upper- and lower-case letters & digits (62 characters, which means each character yields (log 62 2) = 5.9542 bits of entropy), you want a 22-character truly random password. 'xNl5gkbgXntyxi3oNO1dML' is a perfectly fine password (save for the fact that it's now public).

According to the NSA [1], 256-bit keys should be used to protect data up to TOP SECRET; that works out to 43 characters. Hence, 'TIdmzj1COc9ECwcilyQYVfLl5Dt8ti3UUlDVULrUrfx' is as secure an example password as could be.

(Yes, I'm assuming here that your password-generation algorithm is truly random. If not, do not pass Go; do not collect $200…)

[1] https://www.nsa.gov/ia/programs/suiteb_cryptography/

Re: How we cracked millions of Ashley Madison passwords

#62

Post by ddlatham » Thu, Sep 10, 2015, 2:01 PM UTC

lostcolony wrote: post #42

nilved wrote: post #7

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords? This has always seemed like a non-issue to me because I've been using a password manager for a half-decade. e: Downvoting questions is mean. FWIW I always use bcrypt.

Let's also assume that any given server will never be hacked. It's more realistic.

While uncommon, it's not ridiculous. A site could, for example, decide to generate a user's password rather than allow them to provide their own, thus guaranteeing it be long, random, and unique. However, it's still not a good idea to store such passwords in plaintext.

Re: How we cracked millions of Ashley Madison passwords

#63

Post by hellofunk » Thu, Sep 10, 2015, 2:01 PM UTC

Lawtonfogle wrote: post #57

hellofunk wrote: post #15

Earlier quoted context omitted.

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

Security is a cost center with no output and no drawbacks when you cut it (as the business people see it). So it is often quickly underfunded til some major incident.

That's really strange, isn't it? Because it only takes one major incident for a company to go entirely out of business in many cases. Or for CEOs to get ousted or step down, as in the Ashley case, or any number of other irreversible catastrophes. It would seem to me security should be the most important part of the entire process.

Re: How we cracked millions of Ashley Madison passwords

#64

Post by gvb » Thu, Sep 10, 2015, 2:01 PM UTC

ins0 wrote: post #5

flipp3r wrote: post #2

tl;dr they had a bad implementation and used md5 previously

they stored a static login key generated by md5(strtolower($username).'::'.strtolower($password)); - so they could crack the md5 part easly and bypass the bcrypt encryption

Slightly pedantic: "Discovery 1" email indicates that the $loginkey encryption was the weak md5 method until it was changed to bcrypt in a 2012-06-14 commit.

As a result, any accounts that were created before 2012-06-24 and that did not have their password changed after that date (which would generate a new bcrypted $loginkey) were vulnerable.

Re: How we cracked millions of Ashley Madison passwords

#65

Post by paulmd » Thu, Sep 10, 2015, 2:02 PM UTC

gmac wrote: post #38

JosephRedfern wrote: post #16

Earlier quoted context omitted.

I don't quite follow. If they have access to the server's database, then unless the rest of the DB was encrypted using a key derived from the users password, will they not have access to all the accounts anyway? (edit: I should perhaps make it clear that I'm not suggesting that passwords shouldn't be hashed, merely that if you have access to the database containing the password hash, then in many cases you'd already…

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.

Re: How we cracked millions of Ashley Madison passwords

#66

Post by acveilleux » Thu, Sep 10, 2015, 2:02 PM UTC

dsp1234 wrote: post #44

I recently found out that piwik also uses a login token of the MD5 of the password[0]. So this mistake is still very prevalent. If you want to provide a one-click automatic login to Piwik for your users, you can use the ‘logme’ mechanism, and pass their login & the md5 string of their password in the URL parameters: https://stats.example.org/index.php?module=Login&action=logm... [0] - http://piwik.org/faq/how-to/#faq…

That's actually a whole lot worse than the AM version here. The MD5 hashes themselves are usable as valid password!

And the cracking of the MD5 hash back to original password is fully amenable to rainbow tables. All you need is hashes which you can extract from DB or webserver logs... Or sslstrip'd/HTTP traffic if that's possible.

Re: How we cracked millions of Ashley Madison passwords

#67

Post by felixhandte » Thu, Sep 10, 2015, 2:11 PM UTC

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)

Re: How we cracked millions of Ashley Madison passwords

#68

Post by hardwaresofton » Thu, Sep 10, 2015, 2:11 PM UTC

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

Re: How we cracked millions of Ashley Madison passwords

#69

Post by SixSigma » Thu, Sep 10, 2015, 2:16 PM UTC

hellofunk wrote: post #63

Lawtonfogle wrote: post #57

Earlier quoted context omitted.

Security is a cost center with no output and no drawbacks when you cut it (as the business people see it). So it is often quickly underfunded til some major incident.

That's really strange, isn't it? Because it only takes one major incident for a company to go entirely out of business in many cases. Or for CEOs to get ousted or step down, as in the Ashley case, or any number of other irreversible catastrophes. It would seem to me security should be the most important part of the entire process.

Then the CEO blames the IT dept, shareholders lose their investment and CEO moves on to next job with the bonuses he got for cost cutting still intact.

Re: How we cracked millions of Ashley Madison passwords

#70

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

brusch64 wrote: post #45

valarauca1 wrote: post #9

Earlier quoted context omitted.

Could you recommend a good password manager?

I like KeePass and use it daily.

I use KeePass as well, and have had no problems using SpiderOak to securely sync my password database across devices.

(Though I've heard noises recently about KeePass's .kdbx file format having some known vulnerabilities. Anyone else heard this, or have more details?)