• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Suggestion needed on digesting passwords

 
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You wouldn't use a random salt, you'd use a single fixed salt which you'd need to store somewhere.
 
Ranch Hand
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was thinking of hashing the random salt rather than storing it as it is in the database.
 
Joe San
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 San
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

 
Alas, poor Yorick, he knew this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic