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).
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).
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.
They did it in a trivially stupid way, but it is still a botched attempt at cryptography.
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.
> MD5() isn't a primitive, it is an entire
> implementation.
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)
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.
That's how I read it — and therefore misquoted it — as well.
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.
> 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.
> "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.
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.
Once again, from Wikipedia, https://en.wikipedia.org/wiki/Cryptosystem:
Typically, a cryptosystem consists of three algorithms:
one for key generation, one for encryption, and one for
decryption.
> Do you really think an authentication scheme
> is a cryptographic protocol? Is AES an authentication
> scheme? Is Kerberos a cryptographic protocol? No
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.
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.
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.
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.
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.
But who makes encryption in the first place -- groups?
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.
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.
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
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.
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.
The amount of people telling you to use bcrypt has nothing to do with it. It's the peer review conducted by hundreds of experts that understand information theory that is the indicator. Crypto experts aren't just randomly shifting around bytes and hoping it works, modern protocols all protect against various attacks that you are going to expose yourself to by ignoring them.
Even if you're not an expert, you will immediately hear of any attack on modern crypto because it will be a huge deal. These are algorithms the NSA recommends to other arms of the US government that they are protecting.
If the attack is not made public, you will be screwed anyway if you are a target because all of your OS update mechanisms (package signing, etc) all depend on modern crypto so an attacker with the ability to break that will see your super secret hash function of "count the 1s" anyway.