aspose file tools*
The moose likes Security and the fly likes Suggestion needed on digesting passwords Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Suggestion needed on digesting passwords" Watch "Suggestion needed on digesting passwords" New topic
Author

Suggestion needed on digesting passwords

Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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!


SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42612
    
  65
You wouldn't use a random salt, you'd use a single fixed salt which you'd need to store somewhere.


Ping & DNS - my free Android networking tools app
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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?


Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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

Joined: Sep 26, 2006
Posts: 9519
    
    2

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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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' .









Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18990
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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
Marshal

Joined: Mar 22, 2005
Posts: 42612
    
  65
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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9519
    
    2

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
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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.
 
 
subject: Suggestion needed on digesting passwords