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

Answer: 
Supplementing [Mike Ounsworth](https://security.stackexchange.com/a/169322/63556)'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:

1. I request some large number of accounts in sequence
2. You generate a correspondingly large number of bytes from your PRNG and send them all to me
3. I use those bytes to [infer the internal state of your PRNG](https://jazzy.id.au/2010/09/22/cracking_random_number_generators_part_3.html) at the time when you generated my passwords
4. From this, I infer the internal state of your PRNG at the time when you generated every subsequent user's passwords. Every future password your PRNG generates can be predicted by me. Further, the MT can be run backwards to generate all its previous outputs from a known point in time
5. I have now computed every password in-use by your system without having access to your database

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