KDF followed by a Hash? It is my understanding that a KDF adds entropy, whereas a hash loses information.

I've read that KDF should be used to store passwords. I don't understand why we don't use a KDF and then a hash, so that – if the database of password is leaked – it would also be impossible to figure out the plain passwords.

So storing passwords in a database would be like this:


Use KDF to increase entropy (especially good if users are using short passwords),
Use a hash to lose information,
Store the hash.


Shouldn't this be the advised way to store passwords?
It is my understanding that a KDF adds entropy, whereas a hash loses information.


Password Based KDFs can be seen as hash functions (or families of hash functions, depending on your definition), just ones with a lot of complexity. It is sometimes said that they "add entropy" but that usually means either


they combine entropy from a salt into the password hash (which you can do with any hash function), or
they make the password more computationally difficult to crack as if it had more entropy (also called computational entropy).


PBKDFs and hashes are irreversible; meaning that it is impossible to find a password without performing a brute force or dictionary attack. PBKDF's make it computationally harder to perform a brute force search and the salt makes it impossible to find matching passwords within a database.

Both PBKDFs and hashes "lose information" in the sense that their image (output) is smaller than their input domain. That does not make them stronger, however, since if two passwords give the same output hash, either can be used as authentication.

So using a hash after a KDF is at best redundant and can lead to less security through e.g. increased collisions.