Thursday, November 12, 2009

Hashing alone is NOT a life saver

Hashing is a one way - irreversible algorithm which is used to store passwords in databases.

So - nobody other than you know what your actual password is.

When you create your password - your password will go through the hashing algorithm and the hashed password will be stored in the database.

When you try to login - you enter your password in clear text - then the application will calculate the hash of the entered password and will match that with the hashed password already stored in the database. If matches, you will let in.

How does this make your password safe?

Say somebody hacked in to the database.But - still he cant see your password in clear text. So - he can't login to your account. Hacker will only get access to the hashed password - but not to the password in clear text. Keep in mind - you can't never login with the hashed password. That is bacause - what ever you enter as the password will go through a hashing algorithm and that hashed value will be matched with hashed password in the database. In case if you enter the value you found from the database - which is actually the hashed password - then that will be rehashed by tha application and try to match with the hashed password from the database - which will obviously fail.

But - is this safe enough ?

The hacker who has access to your database can still replace your hashed password with a hash he caculated with a clear text known to him. Then he can login to your account with the clear text known to him - because it will be evaluated against the hash value he replaced in the database.

That is; hashing alone is never safe.

Whenever you store anything in clear text as a hashed value - you need to store it as a salted hash.

In cryptography, a salt comprises random bits that are used as one of the inputs to a key derivation function. The other input is usually a password or passphrase in clear text. Output is the 'salt' value. Now - the application will caculate the hash value of password in clear text + the salt value and store that in the database.

Application will also store the salt value - but for best security, the salt value should be kept secret, separate from the password database.

When a user enters his password for login - the application will retreive the salt value and caculate the hash over both the salt and the entered password - and will match the result with the hash value stored in the password database.

In case a hacker having access to the database replaces the user's password with a hash value of a clear text known to him - still the password verification will fail - bacause now the hash is not just caculated with the password along - it's from both the password and the salt value. In this case if the hacker wants to access user account he should be able to gain access to the database which stores hash values as well.

So - the bottom line is - hashing along is never secure - salted hashing much secure - but all that will make it's hard to break - but never stop from breaking fully.

Although you store clear text passwords as salted hashes - it's never an alternative to not to secure access to the database.


Nabeel Yoosuf said...

Good note for those who implement password based authentication systems. Agree that there is no such thing called 'absolute security'. Instead, we can only raise the bar (difficulty) for attacker to break passwords - salting does exactly that.

Random salting also has the advantage of password indistinguishably; if two users use the same password but random salts, it will produce two different passwords.

If an attacker has access to salts, the effort required to break one specific password is as same as that without a salt. However, if the attacker's intention is to break any password, even with random salt values available to him/her, its much harder to break compared to unsalted hashes.

A good question to think about is to how to separate hashes and salts. Simply having in separate tables won't work; if the attacker has access to hashed tables, there is no reason that prevent the attacker from accessing the salt table.

Another thing is there are some situation where you've got to have the username and password in the clear. For example, database access in an ORM layer. I am not sure if there's a good way to protect such passwords??? other than preventing access to where they are stored - in a file or a table.