tags:

views:

165

answers:

2

Upfront, I'd like to confess to being a complete newbie to cryptography and password security. I'm trying to store passwords in a database being babysat by ruby. My understanding is that plaintext passwords should be appended to a random "salt" and that whole phrase should be hashed by some hashing algorithm such as:

    Digest::SHA1.hexdigest(salt_plus_plainpassword)

Once that string is stored in the database, how does one get it out again to verify that what the user entered is correct if there was a now unknown random salt appended to it?

+4  A: 

The best way to do it is to store the salt is one for each user and it is generated based on the Time at the point they did it.

It's true that once a person has access to your database they can see the salt for users, but if this has happened you have bigger things to worry about.

The way you check your user's password is that you take their clear text input and crypt it with the salt and then compare the crypted_passwords, if they match they are authenticated. I don't believe that storing the salt is an issue as you will need it. If you are worried about SQL injection attacks you are better off securing your application against them rather than not storing information you need, in this case each users salt.

railsninja
Well said.
musicfreak
To elaborate on that: storing the salt is not a problem as its only purpose is to save you from attacks to rainbow-tables. As hashing is irreversible but predictible, attackers could find out the password from unsalted hashes by just looking at the pre-computed hashes of common passwords.To rephrase that: guessing and listing the result of sha1("hello")[1] is easy, guessin the result of sha1("hello" + salt()) is really hard.[1] it is: aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, so whenever i find that in unsalted database, i know the password.
Skade
A: 

Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.

But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!

If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...

Miguel Fonseca