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.
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.
"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).
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
> 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.
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.
> 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.
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.
In the context of the quote, "crypto" means "cryptographic system", which encompasses authentication.
They tried to implement a "secure login token" by leaking the user credentials in quasi-plain text (with the advent of rainbow tables then GPUs, MD5 is barely better than Rot13 nowadays).
But still, there's math in that. Strings form a monoid under concatenation and toLowerCase() is a pure function (probably 'map (_ $ 223) source' for a given subset of the domain).
To keep with your (insulting) analogy, they tried to build a car by pouring mayonaise on a crankshaft when they really needed a trumpet.
By doing so, they ruined the protection offered by their otherwise strong password hash.
Don't roll your own crypto. Also, assuming your interlocutor has a modicum of intelligence is basic courtesy.
> 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.
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.
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.
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.