9 ms·

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 wi

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.
        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.
        11y ago
  - 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.
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.

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.
      - 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.
      - 11y ago
- 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.

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.