Don't use MD5. If you're in the position of creating a new application, there's no reason to use it and about a dozen reasons not to. If a 256-bit hash is too long, crop it. Your quote, "[MD5] is widely known and well-studied" should have ended with "and MD5 is universally considered broken; not a single entity suggests using it."
"Salt is some secret word or character that is added to your encrypted string and that nobody knows about. With salt, reverse-matching pre-hashed passwords becomes much harder." That's not what a salt is. Salts are by definition public and only protect from pre-computed rainbow tables run against an entire database - salts do not, nor are intended to, protect a single user. What you're doing with your "salt" is actually just stretching the password.
If a malicious user does get your generated password, if he or she knows you used this method, your real password will be compromised possibly within seconds. This therefore really just relies on security through obscurity - the more people that see and implement this article, the less secure using it will be.
Suggestions for the application:
Use a cryptographically secure hashing algorithm instead of MD5, like Argon2 or at least a SHA-2 variant. A user won't see the difference between a 0.000001ms hash function and a 100ms hash function, but attackers will. If you don't want to switch algorithms, at least re-hash the result 1,000,000 times or more. Your users likely won't see a difference because MD5 is that easy to hash; GPUs from a decade ago can do 10 million or more MD5 hashes a second.
Don't bother with a "salt". In this case it's relying on security through obscurity. Instead do key stretching or simply require users to supply a long password.
Suggestions for the user:
There's a difference between rolling your own crypto (what this article advocates) and hosting your password manager on your own computer rather than on the cloud. Take the article for what it is, an interesting exercise and learning opportunity, but at the end of the day, use a battle-tested password manager. Don't roll your own crypto. Even security-focused experts get it wrong all the time.
I hope I didn't come off as too harsh. However, it's really important to understand and peer review anything regarding cryptography and user passwords.
Neat idea, but there's a couple problems.
Don't use MD5. If you're in the position of creating a new application, there's no reason to use it and about a dozen reasons not to. If a 256-bit hash is too long, crop it. Your quote,
"[MD5] is widely known and well-studied"should have ended with "and MD5 is universally considered broken; not a single entity suggests using it.""Salt is some secret word or character that is added to your encrypted string and that nobody knows about. With salt, reverse-matching pre-hashed passwords becomes much harder."That's not what a salt is. Salts are by definition public and only protect from pre-computed rainbow tables run against an entire database - salts do not, nor are intended to, protect a single user. What you're doing with your "salt" is actually just stretching the password.If a malicious user does get your generated password, if he or she knows you used this method, your real password will be compromised possibly within seconds. This therefore really just relies on security through obscurity - the more people that see and implement this article, the less secure using it will be.
Suggestions for the application:
Use a cryptographically secure hashing algorithm instead of MD5, like Argon2 or at least a SHA-2 variant. A user won't see the difference between a 0.000001ms hash function and a 100ms hash function, but attackers will. If you don't want to switch algorithms, at least re-hash the result 1,000,000 times or more. Your users likely won't see a difference because MD5 is that easy to hash; GPUs from a decade ago can do 10 million or more MD5 hashes a second.
Don't bother with a "salt". In this case it's relying on security through obscurity. Instead do key stretching or simply require users to supply a long password.
Suggestions for the user:
There's a difference between rolling your own crypto (what this article advocates) and hosting your password manager on your own computer rather than on the cloud. Take the article for what it is, an interesting exercise and learning opportunity, but at the end of the day, use a battle-tested password manager. Don't roll your own crypto. Even security-focused experts get it wrong all the time.
I hope I didn't come off as too harsh. However, it's really important to understand and peer review anything regarding cryptography and user passwords.
Good point! I just wanted to create a basic tutorial, so I've corrected the intro of the post.
Hopefully it doesn't sound misleading now and can be used for learning purposes together with your comments 👍