Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
The site which I maintain has been in production for 3 years. When you register, the site generates a large (20 digit) random hex password for you. It's stored MD5 hashed unsalted.
When I told the lead dev that MD5 is bad for passwords he said if bad guys get it there's no way they can crack it because the password is random. And even if the bad guy cracks it we generate it so users can't reuse it on other sites.
How can I convince him that we need to use best practices? He is very stubborn...
Ok, so the site generates a random password for each user at registration time. An important question is whether a user can can manually set their password later, or if they are forced to use a random site-generated password. Let's look at the two cases separately.
As far as I can tell, this is the scenario you are describing in the question. Unfortunately, your dev is (mostly) right. At least about single iteration of hashing vs a big slow hash. Your question kinda has the flavour of blindly applying "best practices" without considering what those practices were intended for. For a brilliant example of this, here's a good read:
The Guy Who Invented Those Annoying Password Rules Now Regrets Wasting Your Time
Do switch from MD5 to SHA256, probably add a per-user salt, and maybe consider going to 32 char passwords. But adding a big slow hashing function will increase your server load for little to no added security (at least barring any other goofs in your implementation).
The amount of work a brute-force attacker who has stolen your database needs to do to crack password hashes is roughly:
entropy_of_password * number_of_hash_iterations * slowness_of_hash_function
where entropy_of_password is the number of possibilities, or "guessability" of the password. So long as this "formula" is higher than 128 bits of entropy (or equivalent work factor / number of hash instructions to execute), then you're good. For user-chosen passwords, the entropy_of_password is abysmally low, so you need lots of iterations (like 100,000) of a very slow hash function (like PBKDF2 or scrypt) to get the work factor up.
By "20 digits hex digits" I assume you mean that there are 1620 = 280 possible passwords, which is lower than "best-practice" 2128, but unless you're a government or a bank, you probably have enough brute-force security from the entropy of the password alone.
Salts also serve no purpose here because pre-computing all the hashes is like 280 * 32 bits/hash, which is roughly 1 ZB (or 5000 x the capacity of all hard drives on the planet combined). Rainbow tables help this a bit, but quite frankly, any attacker capable of doing that, deserves to pwn all of us.
You still want to hash the password to prevent the attacker from walking away the plaintext for free, but one hash iteration is sufficient. Do switch from MD5 to SHA256 though, and maybe consider going to 32 char passwords.
Commenters on this thread seem obsessed with the idea that, despite your statement that the site generates passwords, users can in fact choose their own passwords.
As soon as the user has the possibility to change the password, the a single hash iteration is no option for storing the now low-entropy password. In this case you are correct that you need to do all the best practice things for password storage.
Either way (user-chosen or random passwords) you probably want a per-user salt.
If user-chosen, then salts are part of the best practices. 'nuff said.
If random, @GordonDavisson points out a really nice attack in comments [1], [2] based on the observation that a db lookup is essentially free compared to a hash computation. Computing a hash and comparing it against all users' hashes is essentially the same cost as comparing it against a specific user's hash. So long as you're happy getting into any account (rather than trying to crack a specific account), then the more users in the system, the more efficient the attack.
For instance, say you steal the unsalted hashed password db of a system with a million accounts (about 220). With 220 accounts, you statistically expect to get a hit in the first 260 guesses. You're still doing O(280) guesses, but O(260) hashes * O(220) db lookups ~= O(260) hashes.
Per-user salts is the only way to prevent attacking all users for the cost of attacking one user.
Supplementing Mike Ounsworth's answer, your dev is probably correct, providing they're generating their random numbers properly.
If you seed your PRNG that generates these passwords badly, then an attacker can infer the state of your PRNG to predict future passwords. For instance, in a hugely pathological case in which you use a Mersenne Twister with an internal state that isn't refreshed between sessions, the following attack is viable:
Make sure you use a cryptographically secure source of randomness. Your language's built-in PRNG may well not be.
Also, how are your users actually going to remember these passwords? Generating something long and unpredictable is just going to cause your users to save password.txt on their desktops. If the password is meant to be stashed in a config file somewhere then you probably don't have any real issue, but if it's something that's supposed to live in a user's head then you're massively overestimating the capabilities of your users, and likely causing them to invent their own security flaws.
As others have said, reversing the MD5 of an 80 bit random number is a hard problem, so if anyone obtained your table of hashes, they probably wouldn't be able to access user accounts.
However, you might want to consider where the users are storing those 80 bit random numbers. It probably isn't going to be in their heads. Best case, it's in a reasonably secure keychain or password repository app. Worst case, they'll have a file with PASSWORDS_FOR_YER_APP.TXT in their home directory.
MD5 as you say is insecure, mainly because of discoveries in 2013 that allow it to be collision-attacked in 2^18 time (Apparently less than a second on modern machines).
Regardless of whether of not the password is going to be used on other sites, your site is still insecure. Just because it's random and thus won't appear on lookup tables of any kind, doesn't mean it can't be broken via collision. That means that if somebody gets the hash, they can pretty easily determine something that will function as a password, assuming you check the hashes.
As others have said, use a better method - SHA family are good, but many prefer SCrypt and BCrypt for passwords, and if its randomly generated passwords you're dealing with you probably won't need salt.
