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

  • 2
    See this same question on Stack Overflow: stackoverflow.com/questions/247304/…
    – Matt
    Jun 6, 2012 at 18:38
  • 3
    I am more concerned about storing passwords with no salt.
    – Woot4Moo
    Jun 6, 2012 at 19:32
  • 2
    @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, 2012 at 20:39
  • I was just asking for the DB field, there are enough other questions and answers about safe passwords...
    – powtac
    Jun 6, 2012 at 23:23

3 Answers 3


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.


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 https://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.


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

  • Not that "hashing the hash" is recommended of course. Many hash functions include an interaction count - not to "encrypt further" but to slow the process down making brute force approaches more difficult. Oct 5, 2016 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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