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?
    – Sjoerd
    Mar 19, 2019 at 8:00
  • i edited my question with more information on the application of the password
    – AXANO
    Mar 19, 2019 at 8:04
  • Do you mean Client side password hashing?
    – Sjoerd
    Mar 19, 2019 at 8:23
  • 11
    "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
  • 6
    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

3 Answers 3


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";
$result = md5($password) . sha1($password) . hash('gost', $password);
echo $result;  //   e10adc3949ba59abbe56e057f20f
// 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).

  • 1
    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).
    – Serverfrog
    Mar 19, 2019 at 13:44
  • 1
    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
  • 7
    en.wikipedia.org/wiki/Kerckhoffs%27s_principle: If you design a security process, assume the attacker knows everything but the key.
    – ThoriumBR
    Mar 19, 2019 at 15:03
  • 4
    "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
  • 3
    @ThoriumBR A good reason to forbid a list of common passwords, as opposed to trying to use arbitrary rules that cover them. ;)
    – jpmc26
    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.
  • 1
    Nice answer but it does not cover the part concerning hashing prior to password usage
    – AXANO
    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


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:

Your way:

ClearText -- MD5 --> HashedClearText -- sent to Server(HTTP(S))-->| |-- MD5/SHA*/... --> HashedHashedClearText

Normal Way:

ClearText -- sent to Server(HTTP(S)) -->| | -- MD5/SHA*/... --> HashedClearText

  • The problem i want to avoid is the centralization of passwords As well as the fact that it is not portable to amnesic operating systems
    – AXANO
    Mar 19, 2019 at 13:22
  • avoid centralization with a single hashed password? amnesic operating systems: portable secure device, beside a Human Head that can't really store many Passwords pretty well
    – Serverfrog
    Mar 19, 2019 at 13:24
  • you can be forced to decrypt "portable secure devices"
    – AXANO
    Mar 19, 2019 at 13:29
  • 2
    as you can be force to spell out a Password. xkcd.com/538 (how will you decrypt a password storage or device, without telling them the password. The same holds on your case)
    – Serverfrog
    Mar 19, 2019 at 13:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .