Suggestion needed on digesting passwords

[Joe San]

Guys,

I need to secure user passwords in my application and for the very same purpose, I would like to use Message Digest SHA-1 algorithm. I would also in addition like to use a salt hash for soring the complete value in the database. This salt value would be a random generated one. My question is, no when the user needs to be authenticated I do not have the random generated salt anymore. How can I acheive this? I do not want to store the random generated salt in my database. Suggestions needed!

[Ulf Dittmer]

You wouldn't use a random salt, you'd use a single fixed salt which you'd need to store somewhere.

[James Sabre]

You have to store the salt with the digest. The random salt does not have to be secret so why don't you like the idea?

[James Sabre]

Ulf Dittmer wrote:You wouldn't use a random salt, you'd use a single fixed salt which you'd need to store somewhere.

But then you would loose most of the advantage of using a random salt in that only one dictionary would need to be created in an attack. By using a random salt an attacker would need a dictionary to be created for each user. Also, if two users had the same password then this fact could be deduced by looking at the digest values.

[Joe San]

I would definitely go with a random salt. But I really do not get the concept of authenticating it again when the user enters his password. I mean how could I get the original String that I used for generating the random salt hash value? I could very well store the random salt hash + password hash in the database but when it comes to authenticating the user would enter the password String which my application will hash digest it for comparison against the database stored value. Now, what about the random salt hash?

[James Sabre]

You store the random salt and the digest in the database. When a user tries to login you extract his random salt from the database and generate the digest from the salt and the password he has tried to authenticate with. If this digest matches that in the database then the user is probably who he says he is.

[Joe San]

I was thinking of hashing the random salt rather than storing it as it is in the database.

[Joe San]

James Sabre wrote:You store the random salt and the digest in the database. When a user tries to login you extract his random salt from the database and generate the digest from the salt and the password he has tried to authenticate with. If this digest matches that in the database then the user is probably who he says he is.

Hold on. Did you mean that I need to generate the digest from the salt and the password? Isn't it that we generate the digest and store this digest in the database?

[Joe San]

Here is my thought on this:

1. User enters a password during registration
2. My app generates a random salt per user (which is a random String), then I generate a hash out of this random salt using SHA-1 algorithm
3. Generate a hash for the entered password
4. Append the random salt hash to the password hash
5. Store this combination hash as is in the database

Now, the question is how to authenticate the user later? I lost my original random salt String. So here is where I need suggestions.

[James Sabre]

When the user registers he provides a user name and password. You then generate a random salt and generate the digest of the concatenation of the salt and the bytes of the password. Store the salt and digest in the database using the user name as primary key.

stored digest = digest(random salt + password at registration)

When a user logs on he provides his user name and password. You lookup the user in your database using the user name as primary key and extract his salt an the digest. Using this salt and the bytes of the password the user has just entered you create the digest. You compare this new digest with the one you extracted from the database.

new digest = digest(random salt extracted from the database + password just entered)

Compare this 'new digest' with the 'stored digest' .

[Joe San]

Is the random salt just a random String of a specified length that I specify? If yes, then how would it minimize the chance of a dictionary attack or a birthday attack against the hash stored passwords? I mean if a hacker gets access to the password table, then he also has access to the random salt and he can append it to the hash and run his dictionary to crack the original password? Am I thinking stupid?

[James Sabre]

Joe Harry wrote:Is the random salt just a random String of a specified length that I specify?

Not normally string - just an array of random bytes. Cryptography uses bytes in preference to strings and characters.

If yes, then how would it minimize the chance of a dictionary attack or a birthday attack against the hash stored passwords? I mean if a hacker gets access to the password table, then he also has access to the random salt and he can append it to the hash and run his dictionary to crack the original password? Am I thinking stupid?

Without the random salt the attacker just needs to create one digest(potential password) -> password dictionary from his list of potential passwords. He then just looks up each stored hash in this map. N users 1 dictionary. Very quick.

With the random salt the attacker needs to create a digest(random salt + password) -> password dictionary for each user. N users requires N dictionaries. Much slower.

[Henry Wong]

Joe Harry wrote:Is the random salt just a random String of a specified length that I specify? If yes, then how would it minimize the chance of a dictionary attack or a birthday attack against the hash stored passwords? I mean if a hacker gets access to the password table, then he also has access to the random salt and he can append it to the hash and run his dictionary to crack the original password? Am I thinking stupid?

Yes. It doesn't stop a dictionary attack. It does slow it down a bit, as the attacking program can't pre-generate the reverse dictionary, as there are way too many possible salt / word combinations. It also help lower the targeting too -- as if you see two users with the same hash, it is more likely that they are using a word (assuming that they are not related).

Henry

[Joe San]

James Sabre wrote:

Joe Harry wrote:Is the random salt just a random String of a specified length that I specify?

Not normally string - just an array of random bytes. Cryptography uses bytes in preference to strings and characters.

If yes, then how would it minimize the chance of a dictionary attack or a birthday attack against the hash stored passwords? I mean if a hacker gets access to the password table, then he also has access to the random salt and he can append it to the hash and run his dictionary to crack the original password? Am I thinking stupid?

Without the random salt the attacker just needs to create one digest(potential password) -> password dictionary from his list of potential passwords. He then just looks up each stored hash in this map. N users 1 dictionary. Very quick.

With the random salt the attacker needs to create a digest(random salt + password) -> password dictionary for each user. N users requires N dictionaries. Much slower.

Now let us imagine a scenario wherein the hacker has access to my password table and it is in this password table I have the salt byte and the password stored. Here it is much like a N to 1 case where in the hacker knows the salt and he just need to generate the passwprd from his dictionary. Am I correct?

[Joe San]

The reason why I"m asking this is due to the fact that my application has some restricted pages and access to these pages will be limited to a set of users (less than 10 or 20). I"m trying to protect these pages with as much security as possible.

[James Sabre]

Joe Harry wrote:

Now let us imagine a scenario wherein the hacker has access to my password table and it is in this password table I have the salt byte and the password stored. Here it is much like a N to 1 case where in the hacker knows the salt and he just need to generate the passwprd from his dictionary. Am I correct?

Since each user has a different salt then you need a dictionary for each user. Without the salt the same dictionary can be used for ALL users.

[Ulf Dittmer]

Joe Harry wrote:I"m trying to protect these pages with as much security as possible.

In that case, consider two-factor (or even three-factor) authentication.

[James Sabre]

Joe Harry wrote: I"m trying to protect these pages with as much security as possible.

Password based authentication is not really a very strong authentication mechanism. You might do better to consider a public key based approach using client side authentication with SSL/HTTPS.

[Joe San]

Did you mean the j_password, j_username techniques? I was considering to secure those pages using session state, password authentication and using https.

[James Sabre]

Joe Harry wrote:Did you mean the j_password, j_username techniques?

No. I can't find a good on-line reference at the moment but you should get the flavour from http://www.herongyang.com/JDK/ssl_client_auth.html . Google is then your friend.

I was considering to secure those pages using session state, password authentication and using https.