Live data from Hacker News

How we cracked millions of Ashley Madison passwords

cynosureprime.blogspot.com

81–90 of 173 posts

Re: How we cracked millions of Ashley Madison passwords

#81

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

> 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 reaching the DB is to sign it cryptographically. The loginKey can be $randomString+sign($randomString). The endpoint can check the signature before doing more costly things like a network request.

Re: How we cracked millions of Ashley Madison passwords

#82

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.

> Their CEO was probably the single most selfish douchebag I'd ever met.

He ran a website for men wishing to cheat on their wives. The one follows the other as night follows the day.

Re: How we cracked millions of Ashley Madison passwords

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

What's the risk of using plaintext passwords if we assume every user is employing long, random, unique passwords?

This assumption is known to be false. We should not design systems around this assumption. If we do, popping a random startup will give up Gmail accounts, by the thousands to tens of thousands, and since we've settled on email accounts as The One Ring To Your Identity that imperils their brokerages, domain registrars, employers, World of Warcraft characters, physical safety, privacy, cat photos, etc.

Re: How we cracked millions of Ashley Madison passwords

#84

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 "never roll your own encryption" -- history is full of examples why and we all know that encryption is hard.

But who makes encryption in the first place -- groups?

Re: How we cracked millions of Ashley Madison passwords

#85

Earlier quoted context omitted.

Could you recommend a good password manager?

I'll second nilved's suggestion of KeePass . The database is encrypted and stored on the local machine. I currently use Syncthing to share it between my devices.

Likewise, I'm very happy with this exact setup after coming from a mix of memorized password and site-dependent password-generation schemes.

I'm on Mac and found KeePassX to be a better solution than the original KeePass, it's much lighter weight. My only hope is that KeePassX gets browser integration at some point via keepasshttp - https://www.keepassx.org/dev/issues/91

Re: How we cracked millions of Ashley Madison passwords

#86

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 "never roll your own encryption" -- history is full of examples why and we all know that encryption is hard. But who makes encryption in the first place -- groups?

and those crypto experts? They usually spring fully formed from the head of Zeus.

Re: How we cracked millions of Ashley Madison passwords

#87

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

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

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 do maths, they didn't design their own encryption scheme." They did not, so therefore they did not.

Now you can argue the merits of using an off-the-shelf authentication/login scheme (e.g. Kerberos, OpenID, ASP.net's authentication provider, etc) and I would agree. But that isn't what you said, you specifically said they rolled their own "encryption" which they did not.

Re: How we cracked millions of Ashley Madison passwords

#88

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 "never roll your own encryption" -- history is full of examples why and we all know that encryption is hard. But who makes encryption in the first place -- groups?

Yup, groups of expert mathematicians, also known as "cryptographers". They create and review on another's schemes.

The author of a scheme can be a single competent person, but it would be unwise to trust it before peer review, regardless of the author's track record.

Re: How we cracked millions of Ashley Madison passwords

#89

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

We updated the title to something less misleading.

Re: How we cracked millions of Ashley Madison passwords

#90

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

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

It's not going as far as rolling your own md5 implementation though, which is something I've seen in places.
Post reply on HN