In the past I used varchar(255)
for storing hashed passwords (no salt). Is this still enough? Or are longer fields required?
![](../../users/profiles/2829.webp)
- 769
- 2
- 7
- 11
-
2See this same question on Stack Overflow: http://stackoverflow.com/questions/247304/mysql-what-data-type-to-use-for-hashed-password-field-and-what-length – Matt Jun 06 '12 at 18:38
-
3I am more concerned about storing passwords with no salt. – Woot4Moo Jun 06 '12 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 06 '12 at 20:39
-
I was just asking for the DB field, there are enough other questions and answers about safe passwords... – powtac Jun 06 '12 at 23:23
3 Answers
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.
![](../../users/profiles/1983.webp)
- 2,878
- 1
- 19
- 27
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.
![](../../users/profiles/4967.webp)
- 2,866
- 17
- 18
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))
![](../../users/profiles/4967.webp)
- 2,866
- 17
- 18
![](../../users/profiles/10414.webp)
- 1,527
- 7
- 11
-
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. – Chris Walsh Oct 05 '16 at 08:20