Storing metadata about password hashes in the database?

I was talking to a friend of mine and he stated that to store user passwords in the database, he, and I quote:

1. Takes a users password
2. Hashes it with a random salt
3. Then, he prefixes the result of #2 with the hash type and the salt, joining them with a pipe delimited string. (e.g. SHA1|RANDOMSALT|afde4343....)
4. Stores result of #3 in the db

He claims that's it readable, as he "can instantly know" what type of hash digest is used.

I don't think I've开发者_如何转开发 ever seen this before, but, I'm looking for reasons on why it would be bad aside from the fact than an unauthorized user can instantly know what type of hash is used to encrypt the passwords and the extra space required for storing the field.

My gut reaction is that this approach to working with passwords is silly, as any indication to help an attacker break passwords is a weakness. Any other reasons I should use to convince him that this is a bad idea?

Thanks!

It is a good idea. Everybody does that, including in the /etc/password (/etc/shadow...) file on Unix systems.

Any decent security model will assume that the attacker knows what kind of hash function is used, if only because the hashing system is a piece of software, store on a hard disk. Conversely, believing in the virtue of not announcing which hash function is used is akin to security through obscurity and that's bad.

So do not try to convince your friend that what he is doing is bad. Instead, let him convince you that what he is doing is good.

PS: this is not password encryption, this is password hashing. Hashing is not a kind of encryption.

It's also good practice to store the hash "cost" (number of times the hash has been stretched), even crypt() does that. Possibly, the worst issue is that you first have to query the database (to know the salt, cost, algorithm) and then check against your generated hash, this requires an extra trip to the DB.

Why is this a good practice? Well, if you have user-specific salts, they have to be stored somewhere... Also, you may (in the future) want to escalate the cost (number of times a hash is "re-hashed") of your hashes to keep up with Moore's Law, if you don't know the original cost you wont be able to do anything.

I strongly recommend that you read this blog post about (secure) password hashing.