Trjtdtk

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.

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

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.

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