7 ms·

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 t

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

hardwaresofton 11y ago
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).
- snowwolf 11y ago
  They generated login tokens using md5 hashes of strings that included the password. This is rolling your own encryption.
  - Someone1234 11y ago
    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.
    - pygy_ 11y ago
      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.
      - Someone1234 11y ago
        > 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 authentication, but the term "rolling your own encryption" clearly relates to the encryption-part of the authentication routine. People regularly roll their own authentication routines (even if that within its own right is a bad plan). I am in no way defending that code. It is garbage. But people in this thread have clearly misunderstand the warning against "rolling your own encryption." Or don't know what encryption is.
        frankzinger 11y ago
        > MD5() isn't a primitive, it is an entire > implementation. No, it's a primitive. From https://en.wikipedia.org/wiki/Cryptographic_primitive 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, etc. ... Combining cryptographic primitives to make a security protocol is itself an entire specialization. Most exploitable errors (i.e., insecurities in crypto systems) are due not to design errors in the primitives (assuming always that they were chosen with care), but to the way they are used, i.e. bad protocol design and buggy or not careful enough implementation. This last bit is usually what is meant by "don't roll your own crypto". Granted, the parent said "encryption", but he meant "crypto", and I thought that was quite clear from the context.
  - eterm 11y ago
    It's not going as far as rolling your own md5 implementation though, which is something I've seen in places.
- pygy_ 11y ago
  > 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.
  - hardwaresofton 11y ago
    Yeah, I'm familiar, which is why I was surprised they had to deal with this at all -- most frameworks handle sessions like this for you automatically...
  - jdmichal 11y ago
    If you're going to signing, you may as well go all the way and just use an encryption + signing mechanism. Then you can store actual data in the token -- within reasonable transmission limits, of course.
hellbanner 11y ago
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?
- chetanahuja 11y ago
  and those crypto experts? They usually spring fully formed from the head of Zeus.
- pygy_ 11y ago
  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.
- rnovak 11y ago
  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/ http://csrc.nist.gov/
  - pjscott 11y ago
    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 http://competitions.cr.yp.to/index.html [2] https://password-hashing.net/ https://password-hashing.net/
- saalweachter 11y ago
  The short answer is "don't be a dilettante". If you want to do crypto, you have to do crypto. You can't just code up an algorithm one weekend and use it for the rest of your life (or the rest of your business's short life). You have to code up a bunch of algorithms, read a bunch of other people's implementations, learn the strengths and weaknesses of different techniques, follow the trade literature, go to conferences, argue with other cryptographers over beers. Be plugged into the sorts of networks which will let you know when your favorite crypto technique is starting to become weak. It's fine to have a diverse set of interests, try your hand at various things. But some things you have to really commit to. You can get away with half-assing a lot of things, but some things -- like cryptography -- need to be fully-assed.
sctb 11y ago
We updated the title to something less misleading.
rnovak 11y ago
This should be extended to "Never roll your own security", because that's really the crux. As many, many people have pointed out in the past, that's why books like Modern Cryptography exist. In these books, they basically say "hey, use these functions and these parameters, and you probably wont die", but in this case, ALM said "screw those parameters, we're smarter than you!!!!" and rolled their own security. As noted by the article, bad move.
jszymborski 11y ago
> 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
- snowwolf 11y ago
  They did actually change the title [1] - It was misleading before, and in fact the heading of the article still is - "How we cracked millions of Ashley Madison bcrypt hashes efficiently" - impliying they are able to crack bcrypt efficiently (they can't). [1] https://news.ycombinator.com/item?id=10198351 https://news.ycombinator.com/item?id=10198351
compbio 11y ago
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.
- hardwaresofton 11y ago
  no no no no no no no no please no. There are well documented reasons to use bcrypt/scrypt/etc over things like MD5/SHA1/SHA2. It's mainly a problem of hashing speed. It is also not impossible to understand how these algorithms work (and understand why they are more safe/take more time). If your password hashes are dumped, it's a question of time before they're decrypted. Depending on the algorithm you use, that time can either be minutes/hours, or it can be days/months/an infeasible amount of time. You are correct that the implicit chain of trust around why you should use those things should not be free of suspicion, but that is a terrible reason to not use state-of-the-art techniques. Modern crypto is demonstrably hard to crack because of mathematics. The question of whether it is all broken is there, but it's much harder to break/cheat mathematics than anything else (and again, proofs exist to prove stuff). DO NOT build your own encryption, or put your own "twist" on any existing well-known methods. What you think is clever might take an attacker 10 minutes to figure out. Take a small pill of humility, you're not as smart or original as you think you are. There is no "break modern crypto" toolkit. Most toolkits that script kiddies use are around broken APPLICATION of security intense. Assuming RSA/AES are not broken, then only theorized attacks require quantum computers. In 2015, it is highly unlikely that your adversary will have quantum computers, unless they are the NSA, and then your problems are much bigger than that (ex. if you interact with any company in the US, you are hosed). The overwhelming majority of businesses are compromised from things like phishing or running (discoverably) outdated software on their servers (ex. Some super old version of tomcat with known vulnerabilities, that announces itself in the HTTP header). If you have information crackers want, your little security scheme will get owned. It is better to put your trust in proven/provable mathematics, even if you are not an expert. Arguably, your adversary is the kind of person that ENJOYS solving puzzles. Adding one more puzzle is not going to turn them away, it's going to make it even more fun. When you have a sufficiently bad injury/infection, you don't go try and work up your own remedy, you go to a doctor. The fact that you didn't go to medical school and may not necessarily trust your doctor doesn't make it a good idea to start making up remedies for issues that have been well-studied by others.

hardwaresofton 11y ago

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

snowwolf 11y ago
They generated login tokens using md5 hashes of strings that included the password. This is rolling your own encryption.
- Someone1234 11y ago
  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.
  - pygy_ 11y ago
    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.
    - Someone1234 11y ago
      > 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 authentication, but the term "rolling your own encryption" clearly relates to the encryption-part of the authentication routine. People regularly roll their own authentication routines (even if that within its own right is a bad plan). I am in no way defending that code. It is garbage. But people in this thread have clearly misunderstand the warning against "rolling your own encryption." Or don't know what encryption is.
      - frankzinger 11y ago
        > MD5() isn't a primitive, it is an entire > implementation. No, it's a primitive. From https://en.wikipedia.org/wiki/Cryptographic_primitive 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, etc. ... Combining cryptographic primitives to make a security protocol is itself an entire specialization. Most exploitable errors (i.e., insecurities in crypto systems) are due not to design errors in the primitives (assuming always that they were chosen with care), but to the way they are used, i.e. bad protocol design and buggy or not careful enough implementation. This last bit is usually what is meant by "don't roll your own crypto". Granted, the parent said "encryption", but he meant "crypto", and I thought that was quite clear from the context.
- eterm 11y ago
  It's not going as far as rolling your own md5 implementation though, which is something I've seen in places.
pygy_ 11y ago
> 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.
- hardwaresofton 11y ago
  Yeah, I'm familiar, which is why I was surprised they had to deal with this at all -- most frameworks handle sessions like this for you automatically...
- jdmichal 11y ago
  If you're going to signing, you may as well go all the way and just use an encryption + signing mechanism. Then you can store actual data in the token -- within reasonable transmission limits, of course.

hellbanner 11y ago

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?

chetanahuja 11y ago
and those crypto experts? They usually spring fully formed from the head of Zeus.
pygy_ 11y ago
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.
rnovak 11y ago
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/ http://csrc.nist.gov/
- pjscott 11y ago
  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 http://competitions.cr.yp.to/index.html [2] https://password-hashing.net/ https://password-hashing.net/
saalweachter 11y ago
The short answer is "don't be a dilettante". If you want to do crypto, you have to do crypto. You can't just code up an algorithm one weekend and use it for the rest of your life (or the rest of your business's short life). You have to code up a bunch of algorithms, read a bunch of other people's implementations, learn the strengths and weaknesses of different techniques, follow the trade literature, go to conferences, argue with other cryptographers over beers. Be plugged into the sorts of networks which will let you know when your favorite crypto technique is starting to become weak. It's fine to have a diverse set of interests, try your hand at various things. But some things you have to really commit to. You can get away with half-assing a lot of things, but some things -- like cryptography -- need to be fully-assed.

sctb 11y ago

We updated the title to something less misleading.

rnovak 11y ago

This should be extended to "Never roll your own security", because that's really the crux. As many, many people have pointed out in the past, that's why books like Modern Cryptography exist. In these books, they basically say "hey, use these functions and these parameters, and you probably wont die", but in this case, ALM said "screw those parameters, we're smarter than you!!!!" and rolled their own security. As noted by the article, bad move.

jszymborski 11y ago

> 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

snowwolf 11y ago
They did actually change the title [1] - It was misleading before, and in fact the heading of the article still is - "How we cracked millions of Ashley Madison bcrypt hashes efficiently" - impliying they are able to crack bcrypt efficiently (they can't). [1] https://news.ycombinator.com/item?id=10198351 https://news.ycombinator.com/item?id=10198351

compbio 11y ago

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.

hardwaresofton 11y ago
no no no no no no no no please no. There are well documented reasons to use bcrypt/scrypt/etc over things like MD5/SHA1/SHA2. It's mainly a problem of hashing speed. It is also not impossible to understand how these algorithms work (and understand why they are more safe/take more time). If your password hashes are dumped, it's a question of time before they're decrypted. Depending on the algorithm you use, that time can either be minutes/hours, or it can be days/months/an infeasible amount of time. You are correct that the implicit chain of trust around why you should use those things should not be free of suspicion, but that is a terrible reason to not use state-of-the-art techniques. Modern crypto is demonstrably hard to crack because of mathematics. The question of whether it is all broken is there, but it's much harder to break/cheat mathematics than anything else (and again, proofs exist to prove stuff). DO NOT build your own encryption, or put your own "twist" on any existing well-known methods. What you think is clever might take an attacker 10 minutes to figure out. Take a small pill of humility, you're not as smart or original as you think you are. There is no "break modern crypto" toolkit. Most toolkits that script kiddies use are around broken APPLICATION of security intense. Assuming RSA/AES are not broken, then only theorized attacks require quantum computers. In 2015, it is highly unlikely that your adversary will have quantum computers, unless they are the NSA, and then your problems are much bigger than that (ex. if you interact with any company in the US, you are hosed). The overwhelming majority of businesses are compromised from things like phishing or running (discoverably) outdated software on their servers (ex. Some super old version of tomcat with known vulnerabilities, that announces itself in the HTTP header). If you have information crackers want, your little security scheme will get owned. It is better to put your trust in proven/provable mathematics, even if you are not an expert. Arguably, your adversary is the kind of person that ENJOYS solving puzzles. Adding one more puzzle is not going to turn them away, it's going to make it even more fun. When you have a sufficiently bad injury/infection, you don't go try and work up your own remedy, you go to a doctor. The fact that you didn't go to medical school and may not necessarily trust your doctor doesn't make it a good idea to start making up remedies for issues that have been well-studied by others.