Storing the password

Question

Post reply

Storing the password

Viewing 5 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic. Login to reply

Shailesh Chaudhary Old Hand Points: 377 More actions · Answer 1

I will do the hash compare of user authentication on both sides (Client & Server) whenever the user logs in .

SC

Nadrek SSC-Insane Points: 20039 More actions · Answer 2

Note that the salt (appending something like the username [if it will never change without the password being changed just after as part of the transaction] or the row's primary key or whatever to the password before hashing it is important to prevent cheap dictionary attacks.

The most serious instance: a bad actor/spy/script kiddie gets ahold of the username and password field from the database.

A) if it's stored in cleartext, they win it all.

B) If the password was hashed using just the password, then they JOIN to a table that contains every word in several large dictionaries in the key column... and another column with the hashed value of each of those words. They win all dictionary-based passwords on the cheap.

C) If the password was hashed using the password and a salt, then they have to have every the table from B) separately generated for each possible salt value. This is, of course, much more expensive, which is the goal of security, to make breaking the security more expensive.

P.S. If you can, create a .NET function and use SHA256, SHA384, SHA512 or another reasonably secure hash. SHA1 is the best choice of the hash functions available in HashBytes, but NIST recommended everyone rapidly move away from it years ago (NIST Comments on Cryptanalytic Attacks on SHA-1).

P.P.S. Note further that that NIST statement was made when the cost of SHA-1 collisions was 2^63. As of Eurocrypt, 2009, the cost has dropped down to only 2^52 (SHA-1 collisions now 2^52 -

Cameron McDonald, Philip Hawkes and Josef Pieprzyk)

ETA: SHA-512, etc., CLR function example that I have not tried: Michael Coles: Sergeant SQL - Let's Hash a BLOB

Elliott Whitlow SSC Guru Points: 102402 More actions · Answer 3

I was thinking about Nadrek's comments.

When we approach security we need to assume that attacker knows any clear-text data and the algorithm that we use. Like any other method all we are doing is buying time and making it more painful..

I'm not sure if he was agreeing or disagreeing with the proposed methodology..

Either way, even if you use a set value (per record) as a salt you effectively increase the level of pain to breach it.. Since to guess a password you need to try all(many) of the combinations, and you will yied only that users password. Using only the password in the hash is bad for 2 reasons (which are largely the same). First you can look at the table and see what users HAVE the same password, adding a row level salt means that even if both have the password password it won't be the same hash. Second, tied significantly to the first, is that once you crack one password, you can use it for all users who have the same hash. And having the salt in clear-text is not a significant issue either..

CEWII

Nadrek SSC-Insane Points: 20039 More actions · Answer 4

Elliott W (10/22/2009)
I was thinking about Nadrek's comments.
I'm not sure if he was agreeing or disagreeing with the proposed methodology..
CEWII

The short form:

1) Always hash passwords (to prevent just reading the password)

2) Always salt the password before hashing (to prevent cheap hashed dictionary attacks)

3) If at all possible, hash the salted password and then destroy the cleartext password _before_ it's transmitted anywhere (to prevent interception)

therefore

A) You can never tell a user what their password is. You can only change it for them (or restore it from backup if the salt is still the same)

and

B) If you ever change the salt, you have to ask the user for a new password as well. Be careful choosing salts (primary keys are probably a good choice IF they don't change even when a typo was made entering data)

Elliott Whitlow SSC Guru Points: 102402 More actions · Answer 5

So I think we agree.. The only real question is the choice of the salt..

A further statement that I would make is that the username not be the pkey of the table, but a surrogate key (like an identity), so that any data tied to a user is tied to the record, not to the username.. From that you can choose any record specific salt you like. In a solution I have the id (which is never allowed to change) is the salt for the password and a checksum value of the whole record(yes I'm paranoid..)..

CEWII