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