views:

163

answers:

8

I asked a question yesterday about password safety...

I am new at security...

I am using a mysql db, and need to store users passwords there. I have been told in answers that hashing and THEN saving the HASHED value of the password is the correct way of doing this.

So basically I want to verify with you guys this is correct now.

It is a classifieds website, and for each classified the user puts, he has to enter a password so that he/she can remove the classified using that password later on (when product is sold for example).

In a file called "put_ad.php" I use the $_POST method to fetch the pass from a form. Then I hash it and put it into a mysql table. Then whenever the users wants to delete the ad, I check the entered password by hashing it and comparing the hashed value of the entered passw against the hashed value in the mysql db, right?

BUT, what if I as an admin want to delete a classified, is there a method to "Unhash" the password easily?

sha1 is used currently btw.

some code is very much appreciated.

Thanks

+4  A: 

What you are doing is right, but no, SHA, MD5 and others are one way hashes only so you can't unhash them (well theoretically you could by e.g. brute force). Letting you as an admin delete things, too, should be part of your authorization management.

Daff
Okay, but the password is fetched in the "put_ad.php" file like this: $pass=$_POST['password']; is this okay then, because the ACTUAL pass will be inside this variable until it is hashed... or should I do it some other way?
Camran
You won't ever brute force *unhash* something, only find a string that will digest to the same hash.
alex
@alex: with passwords, attacking the input space is much easier and will most likely yield the original password.
Michael Borgwardt
@Camran: Well the way you are doing it it needs to be transferred as cleartext somewhere. You should be more concernet that the actual transfer is secure, first by using SSL.
Daff
Okay, got it... Lastly, how long should my varchar field in MySql be do you think? 100 in length should be enough right?
Camran
@Camran -- it depends on how much you care about security. **Two basic things** to improve security is to **use secure connection** and **hash password** on client side.
Grzegorz Gierlik
+6  A: 

If you are an admin and have written the code you don't need to know the original users password. As an admin you code in the right for you to do this.

This is the difference between user authentication and user authorisation

CResults
Okay, but the password is fetched in the "put_ad.php" file like this: $pass=$_POST['password']; is this okay then, because the ACTUAL pass will be inside this variable until it is hashed... or should I do it some other way?
Camran
+1  A: 

Read this : http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html then you can start using bcrypt to store your passwords.

Arkh
*"For each password, generate a random number (a nonce). Hash the password with the nonce, and store both the hash and the nonce."* This doesn't work: if they steal your database, they steal both the md5 **and** the nonce, so that's pointless.
Lo'oris
If I get a database full of sha1 hashed password, I can generate 1 rainbow table in some hours then get the easy passwords fast.Now, if I get a database full of hashed and salted passwords, with the hashes (each being unique), I'd have to generate 1 rainbow table per password. If the hashing algorithm is bcrypt with the good parameters, each of these generation can take a very long time. So even with the hashes you are better off using dictionnary attacks / bruteforce. Which bcrypt helps fight as each try takes more than mere microseconds.
Arkh
But in this situation having a random nonce or just using the user ID doesn't make any difference: the attacker will have to brute force each password anyway.
Lo'oris
You have a point. But usually user IDs are auto-incremented integers which are not "big".
Arkh
Yes, but using big or small numbers makes no difference at all: the hash will be completely different anyway, and the rainbow table fails anyway ;)
Lo'oris
At this point of the article they're still not using bcrypt. So in the context of simple salting a rainbow table can easily contain the hash of 1234admin for example. In this case big random salts help getting your bad passwords out of the range of rainbow tables. I agree that bcrypt is a lot better than string concat so you could use simple IDs.
Arkh
+2  A: 

Yes, you got the first part right.

However, there is no way to unhash the password (easily). This is actually the whole point of storing the hashes instead of the real passwords.

You should simply consider putting some logic in your php application, such that when a user with admin rights is logged in, there would be no need to check for the password to delete an entry.

Daniel Vassallo
A: 

No, there is no way to "unhash" a password. Hashing is a one-way process and can not be reversed.

The only way to get a working password for a hash code is brute force; trying to hash different passwords until a match is found.

The easiest way for an admin to be able to log in to a classified is to store away the current hash code and create a new hash code from a temporary password. Afterwards he can just put the original hash code back, and the old password works.

Guffa
+1  A: 

Yes, you are storing the passwords correctly. But as Arkh suggests, bcrypt is a more secure encryption algorithm.

But the password is encrypted on the server, which means that it will be sent over the internet in clear text, unless you use SSL encryption of the connection. Anyone sniffing the line anywhere between you and the user can then in theory read the password. For your usage, that may be acceptable...

I would rather build an admin interface allowing the admin user to delete whatever classified he/she wants, eliminating the need for "unhashing" the password.

Kjetil Watnedal
A: 

Yes you are right, but a password of a user should not be readable anymore, not even by an administrator! So even unhash would be possible (it is not), it would be a clear no go, to decrypt it back to readable plain text!

Another issue is, that you should not just create a hash of the password, because this is not safe. The password could be found out by brute force, means that someone iterate thru the possible password and try to create the hash code he sniffed from the network etc. If he created the same hash, he found the password. But you can use a salted hash. Means that you add a salt (some additional strings which the attacker does not know) to the password and than hash it. e.g. you create a hash of "username-anytextonlyknownbyourapp-password" or something like that.

Enyra
A: 

If the question is "How to unhash password" - answer is - there is no solution to decode hashed value, way one is to brute it(means to find original value by calculating hash and compare with base) but it very slow process. If password is "strong" it unsolvable task.

If the question is "How to manage passwords" - you don't need to use "unhash"

STEVER