6

I'm currently having am amusing debate with a friend, and we simply can't agree on the best method to store salted passwords in a database. The two options on the table are:

  • Storing the hash and the salt together as a string, delimited by some agreed character (for example: "E69B4A103...598D$59FBA6")
  • Storing the hash and the salt in separate fixed-length binary fields

Obvious advantage to the first is only having to retrieve one field, but at the cost of the field being significantly larger (especially when using SHA512 or a large salt), and performance issued with string manipulation later down the road in the application.

Option two has the advantage of being much smaller, but at the cost of a slightly more complex query to retrieve two fields, not one.

Our question is: which option would make the most sense for a large database where performance is a key factor?

Improve this question
9

There are 2 bits of information. This means 2 fields. It is that simple.

In practical terms, selecting 2 columns is zero extra complexity. Having to read a large field to parse one bit out is unnecessary complexity and performance overhead.

A couple of SO questions on storing salts with hashes

Improve this answer
3
  • 2
    Large +1 on "In practical terms, selecting 2 columns is zero extra complexity. Having to read a large field to parse one bit out is unnecessary complexity and performance overhead." – Mike Walsh Nov 2 '11 at 14:05
  • This was my thought exactly, the DBMS is designed to deal with information seperation easier than an application can parse strings. What are your thoughts on String vs Fixed-Length Binary field though? Two separate strings, or two separate binary fields? – TC Fox Nov 2 '11 at 23:04
  • 2
    salt as string, password as fixed binary – gbn Nov 3 '11 at 5:06

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.