# Hashing password to increase entropy

Is it secure to hash a password before using it in an application to increase password entropy?

Does this practice increase entropy when a PBKDF is used in the application itself or does the PBKDF itself increase the password entropy?

If a random password is hashed with md5 will the output provide a 128 bit entropy?

EDIT: It is meant to use the result of the hash function as a password for cryptographic functions and applications like AES-256, email and access to computer systems.

The procedure used will be password -> hash of password -> application

EDIT 2: E.g if an email application requests a password during registration, the intended password will be hashed locally before being provided to it.

• For what do you want to use it in your application? Mar 19, 2019 at 8:00
• i edited my question with more information on the application of the password Mar 19, 2019 at 8:04
• Do you mean Client side password hashing? Mar 19, 2019 at 8:23
• "If a random password is hashed with md5 will the output provide a 128 bit entropy?" - if the passwords consists of 8 random upper-case characters there are at most 26^8 possibilities which is far from 2^128. Putting some hash behind this will not magically add entropy since a hash is deterministic. Mar 19, 2019 at 8:24
• Again, a hash is a deterministic algorithm. At most you will loose entropy with this (for example when using MD5 on a password with 10000 characters) but never have entropy added. Mar 19, 2019 at 8:27

No, you don't increase entropy by hashing it once, or twice, or ten times. Consider entropy as it is seem from the input, not the output. You cannot add entropy using a deterministic process, as the entropy of the result does not count.

Even if you have some code like this:

``````\$password = "123456";
// 8941b84cdecc9c273927ff6d9cca1ae75945990a2cb1f
// 81e5daab52a987f6d788c372
``````

And you end up with a scary looking 136-byte string, the password is still `123456`, and any attacker bruteforcing your hashed password will have to try, on average, only once, as `123456` is the top worst password on almost every single list.

If a random password is hashed with md5 will the output provide a 128 bit entropy?

No, MD5 is deterministic, so if the attacker knows the string is a MD5 hash, the entropy of it is the entropy of the random password you supplied.

To make the password more secure, use a proper key derivation (PBKDF2 is a good one), ask the user for a longer password, and check if the user is following basic password rules (no chars repeated in a row, proper length, mixed digits and chars, mixed case, things like that).

• The point that i find is problematic is that the OP Posted that the User is himself that don't want to enter a clear text password into a Website form and wanted to hash it before entering it. (or use now a key derivation before entering it into the form). Mar 19, 2019 at 13:44
• This answer assumes that the brute force attacker knows what hash was used to create the derived password, as well as any salt that might be added in the process. If the hashing is done where the attacker has no way to know the algorithm and the salt, the derived password has the added entropy from that uncertainty about the hash and salt. One could consider this a form of two-factor authentication, in which the salt and algorithm held in the hash software represent the second factor.. Mar 19, 2019 at 14:58
• en.wikipedia.org/wiki/Kerckhoffs%27s_principle: If you design a security process, assume the attacker knows everything but the key. Mar 19, 2019 at 15:03
• "Fun" fact. When you concatenate hashes of passwords like that, one (sort of counter intuitively) limits their password hashing scheme's resistance to password recovery to that of the weakest hash. For example `argon2(salt, password) . md5(salt, password)` is as easy to brute force as `md5(salt, password)`. Mar 19, 2019 at 22:43
• @ThoriumBR A good reason to forbid a list of common passwords, as opposed to trying to use arbitrary rules that cover them. ;) Mar 19, 2019 at 22:56

A key derivation function will not increase the entropy, but it does make things more secure. A KDF has the following functions:

• It creates a key of the correct length. Many encryption algorithms take a fixed size length, such as 16 bytes. By using a KDF you can use a password of any length.
• It distributes the entropy of the password over the whole key. Encryption algorithms are meant to work with random-looking keys. If you use `1000000000000000` as key, this can introduce security issues in the encryption algorithm. A KDF scrambles the password into a random-looking key.
• It takes time. To slow down brute-force attacks, key derivation can be made slow so that attempting many passwords takes an unreasonable amount of time.
• Nice answer but it does not cover the part concerning hashing prior to password usage Mar 19, 2019 at 8:21
• Your second point doesn't seem like a pertinent security point to me - a hash is just as likely to end up as `1000000000000000` by chance as it is to be `CE8227D9AC87DD92` and I don't believe that a good encryption system is supposed to become any more transparent when using a uniform-looking key as opposed to a random-looking key. Mar 20, 2019 at 2:16

TL;DR

Hashing a Bad Password before sending it to some Server as Password is more time intensive, uncomfortable and less secure than a simple Password manager.

The Question seems to aim to misuse a Hashing Algorithm as a very simple Password Manager.

Use a real one or any real Password manager.

I will use your example to show why it will be a bad idea:

• You have the not so "entropy-rich" password 1111111111111
• it will have the hash 9DCBF642C78137F656BA7C24381AC25B

Now a Attacker get somehow a Database where the Passwords are in clear text (happend to often in the past). And why ever he will accidentally search there for hashes that have know plaintext (the not so "entropy-rich" password is one of it). Now he knows that the user with your username/email uses "1111111111111" and then MD5 it, as Password. What is then the benefit you have? One step more someone must take, but security wise there is no real difference.

Here the Difference what could happend in the Real World: