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

101–110 of 173 posts

Re: How we cracked millions of Ashley Madison passwords

#101

Post by rnovak »

hellbanner wrote: post #84
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 "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?

There's a US Govt agency called NIST. They sponsor "contests" basically for academics and engineers to put forth proposals for crypto algorithms, which are then reviewed. I'd read up on here[1], if it interests you at all, you can find the original academic papers regarding each of what became the standards, and I think they have references as to the review process as well.

[1]http://csrc.nist.gov/

Re: How we cracked millions of Ashley Madison passwords

#102

Post by rnovak »

Someone1234 wrote: post #87
snowwolf wrote: post #76

Earlier quoted context omitted.

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…

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.

Re: How we cracked millions of Ashley Madison passwords

#103

Post by artursapek »

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…

Updating them retroactively requires those users to log in again, doesn't it? I have had to do a similar update and you can't just update everyone's hashes retroactively. If you've properly hashed it, you need them to actually input their password again.

Re: How we cracked millions of Ashley Madison passwords

#104

Post by heynk »

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…

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?

Re: How we cracked millions of Ashley Madison passwords

#105

Post by tempVariable »

artursapek wrote: post #103
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…

Updating them retroactively requires those users to log in again, doesn't it? I have had to do a similar update and you can't just update everyone's hashes retroactively. If you've properly hashed it, you need them to actually input their password again.

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 be used to upgrade across the board

Re: How we cracked millions of Ashley Madison passwords

#106

Post by gizmo686 »

heynk wrote: post #104
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…

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?

You could delete the old hash and require users to generate a new one through the password reset mechanism. Generally you would want to combine both approaches, so that only users who do not log in during the transfer window have to deal with setting a new password.

Re: How we cracked millions of Ashley Madison passwords

#107

Post by thedz »

heynk wrote: post #104
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…

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?

This wasn't the PW hashing fucntion. The new method hashes using the bcrypt of the password, which they do have.

Re: How we cracked millions of Ashley Madison passwords

#108

Post by Someone1234 »

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 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 apply here. They didn't create their own encryption scheme. Literally, nowhere in the code examples that I have seen did they reproduce either a popular or their own bespoke encryption routine (no maths == no encryption).

Concatenating strings together and then passing it to MD5() is authentication, but the actual hash function implementation is housed entirely within MD5() which presumably is created by someone who didn't screw it up.

People in this thread seem to want to entirely redefine what the term "encrypt" even means to encompass the entire authentication logic but either by the dictionary[0] or Wikipedia definitions[1] that is not correct.

If people want to create a new phase: "Don't roll your own authentication." I am absolutely fine with that. Just don't misappropiate an existing one.

[0] http://www.thefreedictionary.com/encrypt

[1] https://en.wikipedia.org/wiki/Encryption

Re: How we cracked millions of Ashley Madison passwords

#109

Post by cruise02 »

artursapek wrote: post #103
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…

Updating them retroactively requires those users to log in again, doesn't it? I have had to do a similar update and you can't just update everyone's hashes retroactively. If you've properly hashed it, you need them to actually input their password again.

It's possible to update everyone's password without them logging in. If the old storage was just MD5(password) and you want to update it to MD5(bcrypt(password)), you're out of luck. You need the plaintext password to make that change. If instead you change your new storage to MD5(bcrypt(MD5(password))), you can take all of the hashes currently in your database and update them at one time with MD5(bcrypt(old hash value)).

Re: How we cracked millions of Ashley Madison passwords

#110

Post by rurounijones »

tempVariable wrote: post #105
artursapek wrote: post #103

Earlier quoted context omitted.

Updating them retroactively requires those users to log in again, doesn't it? I have had to do a similar update and you can't just update everyone's hashes retroactively. If you've properly hashed it, you need them to actually input their password again.

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.
Post reply on HN