Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
See this same question on Stack Overflow:… – Matt Jun 6 '12 at 18:38
@Matt Thanks for the hint! – powtac Jun 6 '12 at 18:42
I am more concerned about storing passwords with no salt. – Woot4Moo Jun 6 '12 at 19:32
@Woot4Moo, that's a good point. Powtac, no matter how long a password is, a hash will bring it back down to a certain length. Make sure every user gets their own salt, and the salt changes each time the password is changed. Hashing passwords without salt was a major cause of the LinkedIn leak earlier today. – Matt Jun 6 '12 at 20:39
I was just asking for the DB field, there are enough other questions and answers about safe passwords... – powtac Jun 6 '12 at 23:23

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.

share|improve this answer

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

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.

share|improve this answer

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.