views:

1075

answers:

8

Can users request that their password be emailed to themselves if the password is stored as a hash value?

Is there any way to convert a hash value to the clear text value with the proper information (& what information would you need)?

If a user has the same password hash value stored on two sites, would their password be the same for both sites?

+6  A: 

In short, no. With most hashing algorithms, you can have multiple inputs with the same output. It is often better to offer a password reset option.

Rowland Shaw
+7  A: 

Hashed passwords cannot be retrieved in general (this depends on the hashing function, secure hashes cannot be retrieved). If they have the same hash on two sites, they could have the same password, this depends on the hash salt used by the sites, what method etc.

If your password is securely stored in a good hashing system, a provider should never be able to email you your password, you must reset your password if you forget it.

marr75
+21  A: 

If you're only storing a hash of the password, then no. ...and you should only be storing a properly-salted hash of their password, anyway.

Password reset mechanisms are the proper alternative.

Yoopergeek
+1 for reminding the use of SALT...
Paulo Santos
See my answer below for proper use of salt...storing salt defeats the purpose of using it...
jrista
The purpose of salt is to defeat lookup tables, so that it is not possible to simply hash a large number of probable passwords and look for their hash values. That doesn't rely on keeping the salt secret. Moreover, if you don't store it, how the heck to you check the password?
David Thornley
+2  A: 

There are different types of hashing algorithms. Some are more secure than others. MD5 is a popular, but insecure one. The SHA-family is another more secure set of algorithms.

By definition, a hash is a one way function. It can not be reversed.

http://en.wikipedia.org/wiki/Sha-1

Bryan Migliorisi
+3  A: 

If there was a simple way to recover the clear-text password, there would be no point in hashing the passwords to begin with. At that point you might as well just base64 or ROT13 them. (don't do that!)

As others mentioned, use other password recovery methods. There really is never a good reason to have access to clear-text passwords.

If the hash at two sites is the same, the user most likely has the same password at both. Not 100% guaranteed however, there could be a hash collision, but that is hugely improbable.

whatsisname
And more likely means that neither site added salt.
Ian Boyd
A: 

The general idea behind storing a hash of a password is to ensure the passwords are secure...even from those who have access to the database. Trust is never implicit. A hash is a one-way algorithm, so there is no way to derive the original password from a hashcode. Usually, when a user needs to recover their password that was stored as a hash, you should ask them their secret question, and either email them their temporary password, or email them a temporary link where they can change their password. This ensures that the password is never stored clear text, and is secure from all prying eyes, even those who might be assumed to be trustworthy.

jrista
"and also storing the salt, then you are defeating the purpose of having salt in the first place. " - this is incorrect. You have to store the salt, and if you don't you can't validate the hash. There is no security downside to storing the salt - it is only there to defeat lookup attacks.
frankodwyer
i have to disagree with your comment that slats should be immediately discarded. in your example of password exchange, then yes, the salt is one-time and should be discarded.but in user authentication, a per-user salt should be used and must be stored with the password to make is usable. for example, salting the password with the username prevents pre-computed dictionary attacks since a dictionary is required per-user.
longneck
In all practicality, most programmers don't put salts in the database, because if someone gains access to the database and has the hashes, they'll have the salt too. Salts often live in app code. Another idea is to use calculated salts, such as salting based on when the user joined.
marr75
If the salt can be independently calculated, I suppose that would work, provided of course that it can be reliably and quickly regenerated. Embedding them in the app code means the intruder needs only one rainbow table per site. Putting them in the database means that they can be quickly checked, and effectively prevent the use of a lookup table.
David Thornley
+1  A: 

There is no way to reverse the commonly used hashes. They can be bruteforced (trying every single possible password) or you can use a wordlist (using a list of commonly used passwords) in combination to brute force to speed it up some, but it is still a very slow and CPU intensive process.

The best way, which many sites use, it to create a "Password Reset" button where you enter your username and email, and if they match, it sends you a random password and gives you a link to the login page and you can login with your random password and change your password.

Mentalikryst
A: 

To do this you must have a model with the fields: Hashed_password Salt And you need to know the method user to hash the password( Here I use SHA1) Then you can define in your controller:

def self.encrypted_password(password, salt) string_to_hash = password + "wibble" + salt Digest::SHA1.hexdigest(string_to_hash) end

Next you can compare: user.Hashed_password == encrypted_password(password, user.salt) True means that "password" is the password for the user "user"

Fabianf