password-hashing | Password hashing code | Hashing library

Sorry for being too lazy to review the linked code, but I'm providing two examples for Java and NodeJS with Crypto lib that generate a secret key from a passphrase using PBKDF2 algorithm. You can run both codes in an online compiler - Java code and NodeJs code.

This is the output with a fixed = unsecure salt:

The output of PBKDF2 can be specified. A PBKDF is a password based key derivation function. Generally those have a key expansion phase that allows the output to be specified.

However, if PBKDF2 is used as password hash rather than for key derivation the size of the configured hash is kept; that provides the maximum security that can be retrieved from the algorithm. In this case that's SHA-1 that generates 160 bits / 20 bytes.

Unless you really need text, the output can be stored as static binary of 20 bytes. In your case you should be storing it as base 64 version of the 20 bytes. That should amount to a fixed 28 bytes: ((20 + 2) / 3) * 4 = 28 to calculate the base 64 expansion. However, your code explicitly specifies the output size to be 256 / 8 = 64 bytes. A quick calculation suggests that it always uses 88 base 64 characters for that size.

Producing 64 bytes while using SHA-1 is not a good setting because it requires the inner function of PBKDF2 to run 4 times, giving you no advantage of running it only once to produce 20 bytes, giving advantage to an attacker. An attacker only has to check the first 20 bytes to make sure a password matches, after all, and for that only one of the four runs is required. The method that PBKDF2 uses to expand the key size over the hash size is really inefficient and may be considered a design flaw.

On the other hand, 10.000 iterations is not very high. You should, for PBKDF2:

1. specify the output size of the underlying hash as output size (20 bytes instead of 64 bytes for SHA-1) and
2. use a higher number of iterations (limited by how much CPU time you can spend in PBKDF2).

The size of the password doesn't have any influence on the size of the password hash.

Beware that some password hashes on other runtimes create a password hash string themselves, more compatible with crypt on Unix systems. So they would have a larger output that is not directly compatible.

UserInout : plaintext ==> Send to authentication service,

create account: generate salt, hash given plaintext-password with salt, store in account infos

authenticate: read hash from account info in your database, hash the given plaintext password with the read salt and compare that hash with the hash in your database. That is the simplest way of authentication.

Be sure to always use the individual hash that was created for each account, otherwise the hash will always be different and authentication will fail.