8 ms·

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.
      - pygy_ 11y ago
        > 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. That's how I read it — and therefore misquoted it — as well.
      - Someone1234 11y ago
        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 protocol, which it isn't here. You may have read that Wikipedia entry but I don't think you understood it, it says this quite clearly. To be honest it is just flabbergasting we're even having this discussion. "Encryption" has a very specific meaning that is hundreds of years old, "crypto" is just a shorthand way of writing encryption 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. If people want to create the mantra of "don't roll your own authentication," then more power to you. But none of this has anything to do with "don't roll your own crypto." They categorically did not at any point roll any crypto, encryption, cryptographic protocols, or anything else related. Just custom authentication. As I have said multiple times in this thread: "No maths used == no attempt at rolling their own crypto." It is as simple as that, so unless someone can point me to their bespoke implementation of crypto (i.e. maths) then what you're arguing doesn't make sense. To use an analogy: - Famous mantra is: "Never roll your own car engine." - Article is posted where someone built a custom car using an off-the-shelf engine (even if an old and dangerous one (i.e. MD5)) and it crashes. - Someone replies: "This is why you NEVER roll your own car engine." - I reply: "They didn't roll their own car engine, it was a standard off-the-shelf one!" - Someone replies: "The term 'car engine' (as in "Never roll your own car engine") now refers to the ENTIRE CAR, not just the engine." - I reply: "No the engine is a specific component in the car." (i.e. MD5 is a specific off-the-shelf component in an authentication scheme). - Someone replies: "The term 'car engine' now means 'car.'" (i.e. the term "crypto" now refers to the entire authentication process for some reason). As I said I feel like slamming my head on the table. I don't know another way of explaining this. The fact you think that Wikipedia article has any relation to this topic at all means you're even further from understanding this than I thought. Do you really think an authentication scheme is a cryptographic protocol? Is AES an authentication scheme? Is Kerberos a cryptographic protocol? No, and no. Kerberos USES encryption and AES is used IN authentication schemes, but they're just components in both cases.
- rnovak 11y ago
  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.
  - Someone1234 11y ago
    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 http://www.thefreedictionary.com/encrypt [1] https://en.wikipedia.org/wiki/Encryption https://en.wikipedia.org/wiki/Encryption
    - rnovak 11y ago
      I guess I'm just use to hearing "crypto" used as a term that means both the applied part, as well as the math part, so whenever I see someone else say "don't roll your own crypto", I assume they mean everything from the primitives used all the way to how they used them. Sorry for the confusion
    - joesmo 11y ago
      "Don't roll your own authentication" seems to me to be even more pertinent advice than "Don't roll your own encryption" as it's a much more common mistake that I see at almost every single place I've worked at. I think it's not a common phrase because authentication is really not that hard and most engineers think they can do it properly. My experience, at least, shows that they can't. Everything from plaintext passwords to symmetric encryption happens and it happens at companies one would expect would implement some security. I've seen CTOs and Engineering Directors argue against changing the plaintext passwords till they were blue in the face and I just gave up. Obviously, our industry has done little to educate people on this issue and in almost every single major breach, it's easy to see how this was a key factor in making the leak worse by leaking the actual passwords or their improperly stored "hashes" (because in some cases they're not even hashes).
eterm 11y ago
It's not going as far as rolling your own md5 implementation though, which is something I've seen in places.

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.
    - pygy_ 11y ago
      > 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. That's how I read it — and therefore misquoted it — as well.
    - Someone1234 11y ago
      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 protocol, which it isn't here. You may have read that Wikipedia entry but I don't think you understood it, it says this quite clearly. To be honest it is just flabbergasting we're even having this discussion. "Encryption" has a very specific meaning that is hundreds of years old, "crypto" is just a shorthand way of writing encryption 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. If people want to create the mantra of "don't roll your own authentication," then more power to you. But none of this has anything to do with "don't roll your own crypto." They categorically did not at any point roll any crypto, encryption, cryptographic protocols, or anything else related. Just custom authentication. As I have said multiple times in this thread: "No maths used == no attempt at rolling their own crypto." It is as simple as that, so unless someone can point me to their bespoke implementation of crypto (i.e. maths) then what you're arguing doesn't make sense. To use an analogy: - Famous mantra is: "Never roll your own car engine." - Article is posted where someone built a custom car using an off-the-shelf engine (even if an old and dangerous one (i.e. MD5)) and it crashes. - Someone replies: "This is why you NEVER roll your own car engine." - I reply: "They didn't roll their own car engine, it was a standard off-the-shelf one!" - Someone replies: "The term 'car engine' (as in "Never roll your own car engine") now refers to the ENTIRE CAR, not just the engine." - I reply: "No the engine is a specific component in the car." (i.e. MD5 is a specific off-the-shelf component in an authentication scheme). - Someone replies: "The term 'car engine' now means 'car.'" (i.e. the term "crypto" now refers to the entire authentication process for some reason). As I said I feel like slamming my head on the table. I don't know another way of explaining this. The fact you think that Wikipedia article has any relation to this topic at all means you're even further from understanding this than I thought. Do you really think an authentication scheme is a cryptographic protocol? Is AES an authentication scheme? Is Kerberos a cryptographic protocol? No, and no. Kerberos USES encryption and AES is used IN authentication schemes, but they're just components in both cases.
rnovak 11y ago
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.
- Someone1234 11y ago
  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 http://www.thefreedictionary.com/encrypt [1] https://en.wikipedia.org/wiki/Encryption https://en.wikipedia.org/wiki/Encryption
  - rnovak 11y ago
    I guess I'm just use to hearing "crypto" used as a term that means both the applied part, as well as the math part, so whenever I see someone else say "don't roll your own crypto", I assume they mean everything from the primitives used all the way to how they used them. Sorry for the confusion
  - joesmo 11y ago
    "Don't roll your own authentication" seems to me to be even more pertinent advice than "Don't roll your own encryption" as it's a much more common mistake that I see at almost every single place I've worked at. I think it's not a common phrase because authentication is really not that hard and most engineers think they can do it properly. My experience, at least, shows that they can't. Everything from plaintext passwords to symmetric encryption happens and it happens at companies one would expect would implement some security. I've seen CTOs and Engineering Directors argue against changing the plaintext passwords till they were blue in the face and I just gave up. Obviously, our industry has done little to educate people on this issue and in almost every single major breach, it's easy to see how this was a key factor in making the leak worse by leaking the actual passwords or their improperly stored "hashes" (because in some cases they're not even hashes).

eterm 11y ago

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