This is why I rolled my own cryptography to generate random passwords for each site I use.
There is a tradition here that we tell programmers they must never write cryptographic code, that they will screw it up, and so on. To which I say: Yes, I agree that writing crypto code if you don’t know what you are doing can cause problems. It should not be done unless you know what you are doing; if you think using MD5 in any cryptographic context is secure, you don’t know what you are doing and shouldn’t be writing code using crypto.
If one wishes to write crypto code, the first thing is to realize that it’s very important to choose an algorithm wisely. Use one which has been made by an esteemed cryptographer, has been released to the academic cryptographic community, and has not been broken by said community.
Never try to make your own algorithm. Unless you know the difference between differential cryptanalysis and linear cryptanalysis, you have no business making your own algorithm. Even if you do, you have no business making you own algorithm and using it in production without releasing it to the academic cryptographic community so they can analyze it and see if it’s broken in some way you didn’t see.
It’s not just algorithms. It’s how to use an algorithm. If you don’t understand why it’s a bad idea to use a block cipher in ECB mode, then you probably shouldn’t be writing code that uses a block cipher in live production.
I would not have anyone write crypto code for production use unless they have read Applied Cryptography cover to cover; while somewhat dated (it came out before AES, MD5 getting broken, SHA-3, or post-quantum crypto) it is an excellent introduction to the basics.
That said, I have written my own password generator. I have read Applied Cryptography. I know MD5 is broken. I know to random pad plaintext before encrypting it with RSA. I know not to use a block cipher in ECB mode. I have written cryptographic code used in production and it hasn’t ever been shown to be weak or broken; I have revised the code when purely academic attacks have been made against it: I started transitioning from AES to RadioGatún[32] back in 2007 because, while purely academic, I felt the cache timing attacks made it too insecure for me to continue using it in production code.
My password generator takes a master password, and it appends it to that master password the name of the site I am visiting, then runs it through a strong cryptographic hash (RadioGatún[32], for the record, which has been around for over 15 years and remains unbroken) for over 500,000 rounds, to generate a secure password. Since it’s not an online service, there is no point of failure where hackers could get in to the online site; since it’s not a browser plugin, there is no point of failure where a browser security hole or a Javascript hack can get at my master password.
The code is open source and available here: https://github.com/samboy/PassGen/