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 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.
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?
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.
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?
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.
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.
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.
Compare this 'new digest' with the 'stored digest' .
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?
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.
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).
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?
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.
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
Marshal
Joined: Mar 22, 2005
Posts: 35442
9
posted
0
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.
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.
Did you mean the j_password, j_username techniques? I was considering to secure those pages using session state, password authentication and using https.
0
