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

Re: How we cracked millions of Ashley Madison passwords

#141

Post by ajross » Thu, Sep 10, 2015, 5:21 PM UTC

mentat wrote: post #137

msbarnett wrote: post #126

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

No, but it's resistant to parallel cracking, which is the hole being plugged.

Re: How we cracked millions of Ashley Madison passwords

#142

Post by jszymborski » Thu, Sep 10, 2015, 5:26 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).

> but that's less clickbaity

They cracked millions of AM passwords. That's not an exaggerating, but the fact of the matter.... since when to titles need to be tl;dr's

Re: How we cracked millions of Ashley Madison passwords

#143

Post by lostcolony » Thu, Sep 10, 2015, 5:27 PM UTC

ddlatham wrote: post #62

lostcolony wrote: post #42

Earlier quoted context omitted.

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.

Good luck keeping users by forcing a long, random, unique password on every one that signs up.

Re: How we cracked millions of Ashley Madison passwords

#144

Post by msbarnett » Thu, Sep 10, 2015, 5:34 PM UTC

mentat wrote: post #137

msbarnett wrote: post #126

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

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

Well, obviously. For instance, it lacks the property of being trivially vulnerable to a GPU hashing the entire dictionary with a given salt in 30 seconds flat.

Re: How we cracked millions of Ashley Madison passwords

#145

Post by rnovak » Thu, Sep 10, 2015, 6:08 PM UTC

rnovak wrote: post #102

Someone1234 wrote: post #87

Earlier quoted context omitted.

No it isn't. That is a login routine/authentication. If they had replaced MD5/bcrypt with their own in-house alternative, that would be rolling their own "encryption" (hash function). But as is, they designed a login/authentication scheme that was highly flawed, but used off-the-shelf hash functions to do so (even if MD5 is deprecated at this point for anything security related). To phase this simply: "If they didn't…

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 just realized I typed "encryption", and not "crypto". Totally wrong there, encryption definitely implies math.

Re: How we cracked millions of Ashley Madison passwords

#146

Post by iolothebard » Thu, Sep 10, 2015, 6:12 PM UTC

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…

How would it have been hard?

Seems like a 10 minute fix at most to me to rehash the old password once the user was authenticated then put a flag whether they've been 'fixed' or not. After 3 months deactivate the old passwords and sent them an email reset.

Although AM was in the business of essentially blackmailing their customers. So ease of getting back in was of higher priority apparently.

Re: How we cracked millions of Ashley Madison passwords

#147

Post by sbarre » Thu, Sep 10, 2015, 6:22 PM UTC

hellofunk wrote: post #52

sbarre wrote: post #27

Earlier quoted context omitted.

You'd be surprised how often this happens. I had a similar situation with someone who accidentally used my email when buying a new car. For a while I was getting emails from the Hyundai dealership that had auto-login links that would have let me do all kinds of things, including requesting a (paid) tow of the car from my house back to the dealership , scheduling (or cancelling) maintenance, ordering extras and part,…

This is genuinely amazing to me. And the IT guy that set up that Hyundai system is probably getting paid plenty to do it, despite massive flaws like this.

I bet you someone somewhere is making a business decision to trade technical support costs for their customer's data security..

I bet this happens all the time.

Re: How we cracked millions of Ashley Madison passwords

#148

Post by compbio » Thu, Sep 10, 2015, 6:30 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).

I understand the meme: "Never ever roll your own encryption", but I am stubborn enough to ask: "Why?".

Why use bcrypt over scrypt over pbkdf2? Because crypto experts told you? How could you know it is correct, if you are not able to inspect it? By the amount of people yelling "Use bcrypt"?

I know that in crypto you should expect an attacker to be able to read your source code. If you can keep secrets, while your source is out in the open, then it is good crypto. But does that mean you do not need a script-based salt? An attacker which can get into your database, should be able to get code-read access too right? I don't think so... Databases are leaked on forums without any trace of the source code/app logic. When these people did not roll their own encryption, any attack which is able to beat modern crypto (you will never hear of this, as you are not an expert), could now attack you. They fingerprint the hashes, try to find out which expert roll you used, open their suitcase of crypto breaking tools written by the same expert when she was working for the NSA, under cover of doing a PhD at MIT, and go to town.

Don't listen to me, because I am not an crypto authority, but do roll your own encryption: Give your own twist to it. That is security by obfuscation, and would not put all eggs in the same basket. An attacker has to be able to break your custom scheme now, for every different site/database attacked. It could be simple, it could be near perfect, but it won't be as simple as pressing a button on the "break modern crypto"-toolkits.

If you are one of the few doing this: People will move to less arcane targets in the never-roll-your-own-basket. If you are one of the many doing this, breaking crypto would become an unmanageable field of eggs.

If I was a state actor in charge of keeping secrets and breaking crypto, these two memes: "Never roll your own encryption" and "just use bcrypt" are exactly the memes I would propagate to the tech crowd. Even moreso when you can already break bcrypt (or expect to in 5 years and just store everything that looks encrypted with bcrypt) and want to keep your task manageable.

AM would be harder to crack if they'd ROT-13'd the hashes in the source code.

Re: How we cracked millions of Ashley Madison passwords

#149

Post by jszymborski » Thu, Sep 10, 2015, 6:35 PM UTC

smacktoward wrote: post #70

brusch64 wrote: post #45

Earlier quoted context omitted.

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

From what I've heard, people are generally just concerned that the database is not authenticated whatsoever, and so a malicious actor can modify your database (particularly if it's hosted on Dropbox/etc...).

This doesn't seem like a particularly scary vulnerability, but one scenario that was brought up (though I'm not 100% convinced), is that a malicious actor can corrupt the password for one website, leading you to change the password.

I dunno, don't see it as a huge vulnerability, but I do agree there is little reason for such a database not to be authenticated.

Re: How we cracked millions of Ashley Madison passwords

#150

Post by artursapek » Thu, Sep 10, 2015, 6:37 PM UTC

rurounijones wrote: post #110

tempVariable wrote: post #105

Earlier quoted context omitted.

As far as I know, that is correct.[1] Any change, whether for work factor or algorithm in code still waits for the user to come back and attempt a login, at which point you update the database stored attributes and the hash. I think that if you can update a user's password without them inputting, then you have two problems. [1]not authoritative advice. edit: seems that comments suggest doing the md5(bcrypt(hash)) can…

I thought that a while ago but then someone just pointed out that you bcrypt hash the MD5 hash and support two step (MD5 then bcrypt) until they login at which point you can rehash using only bcrypt.

That's a much smarter approach. Never thought of that.