Password hashes: Fixed-length binary fields or single string field?

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?

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

• https://stackoverflow.com/q/1219899/27535

• https://stackoverflow.com/q/1191112/27535

StackExchange Database Administrators Q#7492, answer score: 9