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

161–170 of 173 posts

Re: How we cracked millions of Ashley Madison passwords

#161

Post by [deleted] »

Someone1234 wrote: post #160
frankzinger wrote: post #155

Earlier quoted context omitted.

> MD5() isn't a primitive, it is an entire > implementation. No, it's a primitive. From https://en.wikipedia.org/wiki/Cryptographic_primitive : Commonly used primitives One-way hash function, sometimes also called as one-way compression function—compute a reduced hash value for a message (e.g., SHA-256) Furthermore: Cryptographic primitives are one of the building block of every crypto system, e.g., TLS, SSL, SSH, et…

It is in the context of building a larger cryptographic protocol. But they aren't building a cryptographic protocol in this case, so none of that applies here at all, even a tiny bit. In this case hashing functions are being used stand alone (both bcrypt and MD5), and therefore they're not cryptographic primitives. The only time they become cryptographic primitives is when they're used as such, in a cryptographic pro…

[deleted]

Re: How we cracked millions of Ashley Madison passwords

#162

Post by stan_rogers »

tempVariable wrote: post #96

Like protecting your business with an industrial grade door locks on a building made of hay. Just a whole lot of cheating going on over there, ouch. edit: I don't know if this came up before, but based on how they stupidly tried to cache the login session tokens with md5, instead of running through the 12 work factor bcrypt, I can assume that they saw this as a bottleneck. Instead of dropping the work factor or doing…

The "remember me" token doesn't need to contain or be derived from any meaningful data at all; it merely needs to be unique to the user so you can associate it with the user, and should be both unpredictable and frequently changed/regenerated. It's just a more persistent version of the session ID you'd be using in any case even if the "remember me" option wasn't selected.

Re: How we cracked millions of Ashley Madison passwords

#163

Post by ecnahc515 »

Osiris wrote: post #158
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…

* MD5 of the bcrypted pass+username * How do you verify that? Since bcrypt generates a random salt when you hash a value, if you MD5 the resulting hash, you lose the salt. So, are they storing the bcrypt work factor and salt but doing an MD5 only on the hash portion? Seems like a needless extra step. Storing the bcrypt work factor, salt, and hash should be sufficiently secure. Unless you meant bcrypt(md5(pass+usernam…

Pretty sure they mean bcrypt(md5(pass+username)) since changing hashing algorithms is generally an additive change.

Re: How we cracked millions of Ashley Madison passwords

#164

Post by InclinedPlane »

TallGuyShort wrote: post #125
encoderer wrote: post #112

Earlier quoted context omitted.

No, you just take the original MD5 of lower(pass)+username and run that thru your new bcrypt. You will have a more complicated authentication process but it's worth it.

The entropy in the resulting hash is almost the same as a salted MD5 though, is it not? You have more bits, but not significantly more possible hashes. edit: I guess most people only start out with short passwords, thus limiting the possible entropy anyway...

There are levels of vulnerability:

1: Vulnerability to a pre-computed table. This hits hard if you are using plain-old MD5 without a salt.

2: Vulnerability to a newly computed table. This will hit you if you use a global salt and a fast hashing/encryption algorithm.

3: Vulnerability to high throughput custom hardware. This will hit you if you use a fast hashing algorithm like MD5. Modern GPU-based algorithms can churn through hundreds of billions of hashes per second on fairly inexpensive hardware. Which means that attacking, say, 20 million accounts it's possible to run through billions of possible passwords (which means a full dictionary attack, the top million most common passwords, plus common ways of combining words to make passwords, plus every random alphanum string up to 9-10 digits) for each and every account in only a month of work.

4: Vulnerability to very weak passwords. This will hit you if you use a slow hashing algorithm and there's no global vulnerability because you use per-record salts (or bcrypt/scrypt).

4 is where you want to be, always. You can't protect against weak passwords, but you can make it expensive for weak passwords to be revealed, and prohibitively expensive for stronger passwords to be systematically cracked.

The entropy of the hashes isn't really relevant since it's the repeatability of the hashing that's at issue. For example, the hash 7c6a180b36896a0a8c02787eeafb0e4c seems to have plenty of entropy, but since it's the MD5 of the string "password1" and you can just google that hash to find out that information, the theoretical entropy is moot.

Re: How we cracked millions of Ashley Madison passwords

#165

Post by etjossem »

notfoss wrote: post #55
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…

Can you open a feature request on their bug tracker to change it to a more secure alternative?

Good call. https://github.com/piwik/piwik/issues/8753

It seems like this has been on the back burner for a while, though ...

Re: How we cracked millions of Ashley Madison passwords

#166

Post by fryguy »

Someone1234 wrote: post #99
pygy_ wrote: post #93

Earlier quoted context omitted.

Cobbling together existing primitives counts as "rolling your own crypto". They did it in a trivially stupid way, but it is still a botched attempt at cryptography.

> Cobbling together existing primitives counts as "rolling your own crypto". MD5() isn't a primitive, it is an entire implementation. As I said, if they didn't do maths they didn't do encryption. You're conflating authentication with encryption, which aren't the same thing at all (just like an engine and a car aren't the same thing, or a heart and a human). Encryption (and or hashing) is an important part of authenti…

MD5 is a primative. Many algorithms specify a hash/compression function (which MD5 is) or a permutation (which AES is) in how they work. Message authentication (HMAC) can use any compression function, key derivation can use any compression function, and so on. Even stream ciphers can use MD5.

People implementing things that use crypto should only be using functions that are "Authenticated Encryption" which specify the full suite like AES-GCM (permutation function: AES, in Galios/Counter Mode), or "Key Derivation Function" (PBKDF2-HMAC-SHA2 or Argon2d-Blake2b). What they've done at AM is implement their own key derivation function using the MD5 primative and concatenation.

Re: How we cracked millions of Ashley Madison passwords

#167

Post by aaron695 »

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…

What's the lesson here exactly?

Lets say they spent the time redoing the passwords, would Ashley Madison be better off right now?

This is a pimple on a elephant. And once you've killed the elephant it's kinda easy to find pimples.

If anything this would have been a distraction from the real issues of however they actually got hacked.

You might see it as a sign that they had bad security, but in hindsight it's all to easy to find signs.

Re: How we cracked millions of Ashley Madison passwords

#168

Post by itslennysfault »

Osiris wrote: post #158
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…

* MD5 of the bcrypted pass+username * How do you verify that? Since bcrypt generates a random salt when you hash a value, if you MD5 the resulting hash, you lose the salt. So, are they storing the bcrypt work factor and salt but doing an MD5 only on the hash portion? Seems like a needless extra step. Storing the bcrypt work factor, salt, and hash should be sufficiently secure. Unless you meant bcrypt(md5(pass+usernam…

There is no need to "verify" it was just a $loginkey used for automatic login. It's just a hash of: md5(lc($usename).”::”.lc($bcrypt-string))

They generate one and store it in the database and just do a basic string compare against the one used to auto-login.

Re: How we cracked millions of Ashley Madison passwords

#169

Post by frankzinger »

Someone1234 wrote: post #160
frankzinger wrote: post #155

Earlier quoted context omitted.

> MD5() isn't a primitive, it is an entire > implementation. No, it's a primitive. From https://en.wikipedia.org/wiki/Cryptographic_primitive : Commonly used primitives One-way hash function, sometimes also called as one-way compression function—compute a reduced hash value for a message (e.g., SHA-256) Furthermore: Cryptographic primitives are one of the building block of every crypto system, e.g., TLS, SSL, SSH, et…

It is in the context of building a larger cryptographic protocol. But they aren't building a cryptographic protocol in this case, so none of that applies here at all, even a tiny bit. In this case hashing functions are being used stand alone (both bcrypt and MD5), and therefore they're not cryptographic primitives. The only time they become cryptographic primitives is when they're used as such, in a cryptographic pro…

  > It is in the context of building a larger
  > cryptographic protocol. But they aren't
  > building a cryptographic protocol in this
  > case, so none of that applies here at all,
  > even a tiny bit.
"Crypto" in the context of "don't roll your own crypto" does not mean "cryptographic protocol", it means "crypto system". The Wikipedia page uses protocols as examples of crypto systems.

  > "Encryption" has a very specific meaning that is
  > hundreds of years old, "crypto" is just a shorthand
  > way of writing encryption
You're wrong. As I said before, in the case of "rolling one's own crypto" it refers to "crypto systems". Not every word containing "crypto" refers strictly to encryption. E.g., MD5 is a "cryptographic hash function".

  > or cryptographic, and neither term is a synonym for
  > authentication.
  > ...
  > I cannot tell if this confusion originates from
  > people not understanding what the words "encryption"
  > or "cryptographic" mean, or from them not
  > understanding the difference between authentication
  > as a broader topic and encryption/hashing as a
  > singular component within it.
Cryptography encompasses more than just encryption. Authentication is included in the definition of "cryptography" here: https://en.wikipedia.org/wiki/Cryptography. An authentication system is totally a crypto system and totally falls under the definition of "cryptography"!

MD5 is a bunch of XORs and MODs. Bcrypt has a bit of that, but mostly it uses Blowfish. Scrypt is used for more or less the same purposes as bcrypt, and is built on top of PBKDF2_HMAC_SHA256. Do you see the difference? Bcrypt and scrypt are built out of things at MD5's level.

Once again, from Wikipedia, https://en.wikipedia.org/wiki/Cryptosystem:

  Typically, a cryptosystem consists of three algorithms:
  one for key generation, one for encryption, and one for
  decryption.
That sounds like bcrypt and scrypt qualify. I don't know, but they are clearly much closer to it than MD5. Anyway, the distinction is not always black and white. The point is to use as high-level and complete an implementation you can find for any crypto-related things you need to do. Including password hashing. MD5 was too low-level, and look at how badly they messed it up. They tried to achieve what bcrypt and scrypt were designed for by using a much lower-level construct in MD5. They rolled their own crypto.

  > Do you really think an authentication scheme
  > is a cryptographic protocol? Is AES an authentication
  > scheme? Is Kerberos a cryptographic protocol? No
No I don't. But an authentication scheme is a crypto system. Kerberos is a crypto system. Hence the term "don't roll your own crypto" would apply to both.

Re: How we cracked millions of Ashley Madison passwords

#170

Post by pjscott »

rnovak wrote: post #101
hellbanner wrote: post #84

Earlier quoted context omitted.

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/

There are also contests run by groups without any NSA affiliation, such as the CAESAR contest for authenticated encryption [1] and, relevant to this subject, the Password Hashing Competition [2], which recently decided on a pretty impressive winner.

[1] http://competitions.cr.yp.to/index.html

[2] https://password-hashing.net/

Post reply on HN