15

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.

AXANO
  • 899
  • 7
  • 23
  • For what do you want to use it in your application? – Sjoerd Mar 19 '19 at 08:00
  • i edited my question with more information on the application of the password – AXANO Mar 19 '19 at 08:04
  • Do you mean Client side password hashing? – Sjoerd Mar 19 '19 at 08: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. – Steffen Ullrich Mar 19 '19 at 08:24
  • yes but the main question is if the entropy will be increased – AXANO Mar 19 '19 at 08:26
  • 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. – Steffen Ullrich Mar 19 '19 at 08:27
  • does the same apply if the procedure is unknown to an adversary? – AXANO Mar 19 '19 at 08:27
  • Depends on how much effort the adversary needs to find out the procedure. If its simple to find out then it will not help much. If you instead use a hash and also some long random key which can never be known to the adversary then this is different - but then it is also not a simple hash anymore. – Steffen Ullrich Mar 19 '19 at 08:30
  • well since the procedure is completely unknown, and the adversary never sees the password clear text since it is processed by the application alter on, does this make it impossible for the adversary to reverse the procedure? – AXANO Mar 19 '19 at 08:32
  • "the procedure is completely unknown" - that you don't explicitly publish the procedure does not mean it will be unknown. On the one side don't estimate the educated guesses an attacker might do. On the other side: source code might leak, binaries might be reverse engineered, coworkers might talk. In general - such security by obscurity should only be used as additional protection which will only be effective for a limited time. – Steffen Ullrich Mar 19 '19 at 08:37
  • maybe i didnt clearly describe the usage of this. It is meant to expand my password before providing it to any application. So if i dont tell it it wont be known. for example if a password is requested during registration, i first hash the intended password and then provide it to the application during registration, – AXANO Mar 19 '19 at 08:44
  • @AXANO Will you hash the password only or will you add something application related (e.g. the app name) before hashing? – mad_manny Mar 19 '19 at 08:53
  • only hash it before providing it to the registration form of an application – AXANO Mar 19 '19 at 09:02
  • So you are trying to enroll your own Password Manager that hashes your password instead of using a new one? – Serverfrog Mar 19 '19 at 11:06
  • well not really enroll a new one but apply some basic principles while avoiding centralization – AXANO Mar 19 '19 at 12:03
  • Entropy is a measure of uncertainty and comes from the process used to generate the secret, and not from the secret itself. If the password correct horse battery stable is not generated randomly, then you don't have the amount of entropy that you think you have, but way less. – code_dredd Mar 19 '19 at 18:51
  • Hashing does not increase entropy. The same amount of information is available in the bits before and after hashing (with some hand waiving). All you do when hashing is [irreversibly] transform the string from one domain to another domain. –  Mar 20 '19 at 12:54

3 Answers3

29

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).

ThoriumBR
  • 53,925
  • 13
  • 135
  • 152
  • 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 '19 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.. – Monty Harder Mar 19 '19 at 14:58
  • 7
    https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle: If you design a security process, assume the attacker knows everything but the key. – ThoriumBR Mar 19 '19 at 15:03
  • Doesn't a hash actually reduce entropy, since there can be collisions? – Barmar Mar 19 '19 at 19:07
  • The probability of collisions are so small, you don't have to think about them. And even less probable on a password which is a very small string. – ThoriumBR Mar 19 '19 at 19:30
  • @ThoriumBR sure, you should assume that while designing. But hash application may still be an uncertainty to an attacker. Are you sure entropy isn’t increased? – Chris Mar 19 '19 at 19:40
  • I thought the top worst password was abcd1234, followed by passw0rd!. – hmakholm left over Monica Mar 19 '19 at 20:26
  • @Chris Kerckhoff's Principle: the attacker knows everything but the key. – ThoriumBR Mar 19 '19 at 20:37
  • @HenningMakholm https://www.forbes.com/sites/kateoflahertyuk/2018/12/14/these-are-the-top-20-worst-passwords-of-2018 – ThoriumBR Mar 19 '19 at 20:38
  • 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). – Future Security Mar 19 '19 at 22:43
  • 1
    @FutureSecurity Good point... "The strength of the chain is the strength of the weakest link". – ThoriumBR Mar 19 '19 at 22:44
  • 1
    Want to upvote for the answer, but really, really want to downvote for the bad password strength advice in "no chars repeated in a row, proper length, mixed digits and chars, mixed case, things like that." The only good thing to enforce there is length. Barring repeated characters can even reduce entropy, as it eliminates a slew of randomly generated passwords. – jpmc26 Mar 19 '19 at 22:50
  • "chars repeated in a row" is to stop users for using 111111111111 or aaaaaaaaaaaaa as password, and as a sysadmin I've seen plenty of those. Those "passwords" are present on every half-decent wordlist out there and are cracked in a heartbeat. – ThoriumBR Mar 19 '19 at 22:54
  • 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 '19 at 22:56
  • It's the 80/20 rule. My arbitrary rule spots 80% of the bad passwords using 20% of the processing effort. A wordlist would cover the remaining 20%, but at 80% cost. – ThoriumBR Mar 19 '19 at 23:57
4

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.
Sjoerd
  • 30,589
  • 13
  • 80
  • 107
  • 1
    Nice answer but it does not cover the part concerning hashing prior to password usage – AXANO Mar 19 '19 at 08: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. – thomasrutter Mar 20 '19 at 02:16
3

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:

Your way:

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

Normal Way:

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

Serverfrog
  • 578
  • 7
  • 18
  • 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 '19 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 '19 at 13:24
  • you can be forced to decrypt "portable secure devices" – AXANO Mar 19 '19 at 13:29
  • 2
    as you can be force to spell out a Password. https://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 '19 at 13:33