As a user, is using MD5-encrypted passwords on websites a good practice?

Question

Disclaimer: This is from a user standpoint. We'll thus assume the target website (say, Paypal or Netflix) already uses a strong hashing algorithm with salts (bcrypt of pbkdf2, for example) and accepts 32-char-long passwords.

Context: let's assume Bob is a user who knows a few things about computers, but isn't an expert. For example, he understands that using strong passwords is a good thing, but he can't remember a long list of complicated passwords. He thus uses only one strong password on all sites, a practice he considers to be risky.

But then it hit him: he doesn't have to remember strong passwords! Instead, he can just remember easy ones and hash them with a simple function to get strong passwords. That way, he doesn't have to worry about database breaches too much, as his stored password would require massive GPU clusters to get cracked in a reasonable amount of time.

This would work this way:

1. Go to target website.
2. Enter username
3. Hash his easy-to-remember password with a fast algorithm to generate a long password
4. Enter hashed password and get authenticated by the website.

Question: Would this be a good, or even acceptable practice? Is this something you could advise someone to do? Why/why not?

This relies a bit on a variant of security through obscurity perhaps: the hacker only has to know a simple password was MD5-encrypted to render this uneffective, or even harmful (because the user will tend to use weaker pre-encryption passwords). As such, this wouldn't work on a large scale, ie. you couldn't tell millions of people to do that.

Thanks in advance for your input!

Answer 1

There's no question that this extra MD5 layer is better than just using the original password.

The question is whether you'd be better off using a Password Manager which simply generates random passwords and stores them in encrypted form.

I do see the elegance of your solution over a Password Manager.

• Since the final password is derived, not stored, then your solution is portable. There is no need to sync passwords over the internet for multiple devices.

• The 'easy to remember' password unlocks the 'actual' password for just one site. This seems better than using a 'single' Master Password to unlock the 'actual' password for any site as a password manager would normally operate.

From a server-side breach perspective, this is such an unusual (Obscure) practice that the attackers will go to easier targets.

However, it is true that a truly random password (from a Password Manager) would be more secure than one from a simple MD5 hash.

I would suggest you extend your solution somewhat.

1. Use a stronger hash, not MD5. Probably you should use PBKDF2, but you could be using SHA-256 or SHA-1 if it is easier for you. Stronger also means slower. So if you use a fast hash, you should add repetition. (number of Rounds)

2. Add some Pepper, which is stored with your hashing program, and has about 72 bits of entropy.

Input this same Pepper, and number of Rounds for the hash algorithm on all your devices, so they all can generate the same passwords. Also keep it in a file somewhere so you can always re-produce your hashing scheme should you lose the electronic copy.

vs a Password Manager

• You have no Master Password, so there is no 100% loss when that password is stolen along with your device data.

• If your device data is stolen, the Pepper is immediately compromised because it is stored in plain form. However, they still have to guess your 'easy to remember' password.

There will be some obstacles regarding password strength requirements. A Password Manager could store a different style password to fit the particular requirement, but your hash program will operate the same for all sites.

• Tweak your hashing program to produce an uppercase letter, lowercase letter, number and some special character. This will fit the needs of most password strength requirements out there.
• It might be necessary to truncate the resulting hash as some sites have a max-length. This is not a big problem. If you only take the first 20 characters of the resulting hash, the strength is not diminished. Only when you get down to about 72 bits of entropy (18 hex chars or 12 Base64) does truncation become a notable weakness.

Answer 2

There's a general principle that a hash function like MD5 cannot add entropy - which means that if this method was a tool, a piece of software that people attempting to discover the password became aware of, it would simply be another rule, another step in their attempts, and would only marginally slow them down.

However, if this was a method that Bob personally used and does not advertise this method of producing his password, it may be that it would effectively add entropy to the password - as it would increase the length and possibly character set of the result. As you say, this is security through obscurity, it relies on nobody knowing Bob's algorithm. If he writes this program, say, has it on his phone and never shares it with anyone.

For Bob, this is probably a benefit. For a general user, it is certainly not a useful tool.

I strongly dislike promoting anything that smacks of security through obscurity, but any "algorithmic" password generation ("Choose 4 words from these lists of words", "Do a random subset of these transforms to this common long word") which may work reasonably to generate strong passwords but break down if the attacker knows the details of the algorithm. This certainly wouldn't be suitable as a published, advised method of choosing a password.