Database field type for password storage?

Question

In the past I used varchar(255) for storing hashed passwords (no salt). Is this still enough? Or are longer fields required?

Answer 1

The size of the field in the database should exactly match the size of the output of your key derivation function. So if the output is 60 characters long, use a varchar(60) (or maybe char(60) if that's smaller or faster in your database).

And please, don't just hash the password and call it a day. Do it right.

Answer 2

A longer database field or different type makes no difference to security, if that is your question.

You should choose a field length that is long enough just to contain the full bit length of the resulting hash. This is for minimum storage overhead and performance only. (See this as a guide http://stackoverflow.com/questions/247304/mysql-what-data-type-to-use-for-hashed-password-field-and-what-length)

A hash algorithm will return exactly the same amount of data (it’s bit length) regardless of how much data is put in to it.

i.e. (password or password + salt or a 100 lines of text) hashed will return exactly the same amount of bits after hashing through the same algorithm.

To increase security you would need to change how you handled hashing, collection and storage of salt (if you do) as has already been mentioned.

Answer 3

Whatever input you use, hashing always produces a result with the same length. Moreover, salting doesn't affect the length of the hash, because you should salt input before applying the hashing function: hash(password+salt). There is no need to use DB fields longer than the length of the hashing output.

What's more, iterating the hashing function doesn't affect the length: length(hash(hash(input))) == length(hash(input))