Web server salt storage

[sathenzar]

There is just so much conflicting information out there I decided to come here and ask some experts. Salt storage, I know how to use salts and how to generate hashes, but what I want to know is what the best method is for comparing the user hash stored in the database being sent from the client. If I have an MVC page that users a login, that login has to post (in SSL of course) the password to the server (which is the same location just with the POST command). What is the best way to post the password securely and then hash it? Google is a great tool but sometimes has too much conflicting info to know what to believe. Some say they keep the salt a secret while others say don't worry about it. I like PBKDF2 with SHA-512 to generate a hash :)

 

EDIT: Also, do you store the salt in a separate field in the user table or do you compute it in some other way?

[wrack]

If you have an SSL then you can use public key to encrypt the password before sending it to the server and then decrypt it on the other end.

 

Keeping in mind though any encryption you do have to be done at a client level and not in code behind as doing so will be done at a server level anyways and thus defeating the purpose of it. Someone correct me if I am wrong.

 

If you use HTTPS then technically you are safe. Nothing is safe but technically...

 

EDIT : I generate 2 salts for a given user and have another field that dictates how they are used.

 

Table Structure:

UserName

Salt1

Salt2

SaltNature

Hash

 

Salt Nature is an ENUM with 3 Values:

Before = Password + Salt1 + Salt2 (I don't actually save the password but I use this formula to calculate the Hash)

Middle = Salt1 + Password + Salt2 (I don't actually save the password but I use this formula to calculate the Hash)

After = Salt1 + Salt2 + Password (I don't actually save the password but I use this formula to calculate the Hash)

 

Hope this helps.

[sathenzar]

Actually it does. Thanks for the advice :) But my general concern was I've noticed some posts from people working at microsoft that they retrieve the hash and salt from their repositories and then create user objects with hash and salt stored in them. Just seems like that would be an easy way for an attacker to grab what they need to start doing look up tables/etc.

[articuno1au]

Yeah, but that's to do with objects in .net.

 

It's not as bad as it sounds. You just load the info into the object, then call the salting function and use the return to compare to the provided data from the client.

 

Unless the user finds a way to dump that object out of memory into a page, you'll be fine (and I don't even know if that's possible).

[Karl L.]

wrack's instructions look correct, but you might also want to take a look at this article on secure salted password hashing. It very thoroughly explains how to do it the right way, and includes examples in numerous languages, including C#.

[+theblazingangel MVC]

  On 09/07/2013 at 01:16, sathenzar said:

There is just so much conflicting information out there I decided to come here and ask some experts. Salt storage, I know how to use salts and how to generate hashes, but what I want to know is what the best method is for comparing the user hash stored in the database being sent from the client. If I have an MVC page that users a login, that login has to post (in SSL of course) the password to the server (which is the same location just with the POST command). What is the best way to post the password securely and then hash it? Google is a great tool but sometimes has too much conflicting info to know what to believe. Some say they keep the salt a secret while others say don't worry about it. I like PBKDF2 with SHA-512 to generate a hash :)

 

EDIT: Also, do you store the salt in a separate field in the user table or do you compute it in some other way?

I'm finding it a little difficult to determine exactly what you want answers to...

• Verifying a login: Search the database for a user record with a matching username (I would avoid any 'LIMIT 1' clause on the SQL query to avoid any possibility of timing attacks from giving away whether a username on its own is valid or not), and return the salt and hash. If a user was found, re-compute the hash using the salt and the POSTed password. Compare this hash with the hash retrieved from the database.
• Secure transfer of password from client to server: SSL (HTTPS)!
• Keeping salts secret... I think you were getting confused over something irrelevant, as mentioned below.
• Storing salts: Store them in a separate field or concatenated to the hash, your choice!

  On 09/07/2013 at 01:32, wrack said:

If you have an SSL then you can use public key to encrypt the password before sending it to the server and then decrypt it on the other end.

 

Keeping in mind though any encryption you do have to be done at a client level and not in code behind as doing so will be done at a server level anyways and thus defeating the purpose of it. Someone correct me if I am wrong.

What on earth are you talking about.

 

  On 09/07/2013 at 01:32, wrack said:

EDIT : I generate 2 salts for a given user and have another field that dictates how they are used.

 

Table Structure:

UserName

Salt1

Salt2

SaltNature

Hash

 

Salt Nature is an ENUM with 3 Values:

Before = Password + Salt1 + Salt2 (I don't actually save the password but I use this formula to calculate the Hash)

Middle = Salt1 + Password + Salt2 (I don't actually save the password but I use this formula to calculate the Hash)

After = Salt1 + Salt2 + Password (I don't actually save the password but I use this formula to calculate the Hash)

 

Hope this helps.

What the hell are you doing? This is just an overly complicated useless mess that's doing nothing to enhance security whatsoever. Keep things simple, use one salt and one means of concatenation in hashing only!

 

  On 09/07/2013 at 13:31, sathenzar said:

Actually it does. Thanks for the advice :) But my general concern was I've noticed some posts from people working at microsoft that they retrieve the hash and salt from their repositories and then create user objects with hash and salt stored in them. Just seems like that would be an easy way for an attacker to grab what they need to start doing look up tables/etc.

I think, as someone suggested above, you're a little confused about what's going on there and worrying about nothing.

 

  On 09/07/2013 at 16:03, xorangekiller said:

wrack's instructions look correct, but you might also want to take a look at this article on secure salted password hashing. It very thoroughly explains how to do it the right way, and includes examples in numerous languages, including C#.

Good article!