views:

396

answers:

5

Hi all,

I am using md5 to encrypt the passwords in my project.

When user clicks on forgot password and submits his email,I have to send His password to him.

But the password is encrypted using md5.Generating new password should not do.Because In this project admin can see all the details of the user. So i have to show the original password to Admin. So The initial password is very important. SO how can i decrypt the password or any other way to send him original password?

Thanks in advance...

+28  A: 

Hashes are not designed to be decrypted, which is why they're often referred to as "one-way hashes" instead of just hashes.

Instead, either...

  1. Generate a new password, hash that, store the new password hash in place of the old one, and email the newly generated password to the user.

  2. Generate a new password, hash it, store it in a field for temporary passwords, and then when the user logs in with that password, prompt them to enter a permanent new password.

  3. Generate a nonce, store it in a field for the nonce, and email the user a link with that nonce which will give them access to a page to enter a new password.

The third option is probably the best all around, since it doesn't leave an actual password (temporary or not) in plain view to someone reading the user's email, and since it utilizes a nonce, once it has been used it can't be used again by a malicious user.

The reason hashing is used for passwords is specifically to prevent them from being stored in a form where a malicious user could determine the password simply by looking at the database.

Edit:

"So i have to show the original password to Admin."

If you are hashing the password, this is not possible. In general, it is actually a bad idea to allow administrators to see users' passwords, because a large percentage of users tend to utilize the same password for multiple things, and the administrator of one thing (say, a company network) is probably not the administrator of many other things (say, a user's online banking system).

MD5 is not an encryption algorithm, it is a hashing algorithm. The two are not the same; encryption is designed to be reversible (hence the complementary term "decryption"), whereas hashing is designed to be one-way only.

Amber
You don't really want to store it in place of the old one...Either use a separate temp_password field, or send a one-time link which he can use to change the password (the second is slightly more secure because the password won't be left in his mailbox).
Tgr
Updated the answer to incorporate more options. :)
Amber
+1  A: 

If the password has been hashed then you'll probably have to create a random password and send that to the user. Then, once they've logged in, take them to the Change Password screen so they can change their password to something more memorable.

Ian Oxley
+1  A: 

One particular purpose (among others) of a hash value is that it's irreversible, if it works perfectly.

The most common way for a "forgot password" functionality is, to generate a new password and tell your user to change it as soon as possible.

Techpriester
+4  A: 

You can't. The reason cryptographic hashes[1] are referred to as "non-reversible" is that they can't be reversed. Which is the entire point of using them for password storage - it means that, if a Bad Guy gets his hands on the password database, he can't just reverse the hash to find out what all the passwords are.

I see from your edit that your intent is to display the user's password to the admin user(s) rather than for password recovery by the user himself. This is a Very Bad Idea. Many users attempt to ease the burden of remembering passwords by using the same password for multiple systems, which means that displaying their password in your system has a high probability of compromising their accounts on other systems.

True story: Back in 2000, I took a job at a startup that produced voicemail systems. To introduce me to the product on my first day, the IT director had me create a voicemail account, which I did, then he brought it up in the admin interface. I just about died when I saw my voicemail PIN displayed on the screen for all to see. Partly because it was shockingly bad security practice, but mostly because, even though he didn't know it, he now knew the PIN for my ATM card. That's just bad, bad, bad all around. Don't do that.


[1] MD5 is a hashing algorithm, not an encryption algorithm. The key difference between the two is that, for any given hashing algorithm, there are an infinite number of inputs which will produce the same output (which is why it's not reversible), while encryption has a one-to-one correspondence of input to output.

Dave Sherohman
A: 

Just adding this as a sidenote:

While you cannot "unhash" the MD5 hash, you can look it up in a Rainbow table. That might allow you to send the original plaintext password to the user. I am not suggesting to do that though, because it's just a waste of resources compared to just creating a new password and sending that to the user instead.

From http://en.wikipedia.org/wiki/Rainbow_table:

A rainbow table is a lookup table offering a time-memory tradeoff used in recovering the plaintext password from a password hash generated by a hash function, often a cryptographic hash function. A common application is to make attacks against hashed passwords feasible. A salt is often employed with hashed passwords to make this attack more difficult, often infeasible.

Also see the comments below for additional notes.

Gordon
To avoid downvoting this, I'll just say it's a really really really stupid idea to try and decrypt the password which is not useful at all. Don't try and decrypt the password, as this answer says (whilst it is theoretically possible).
David_001
Even if you have a rainbow table containing a matching hash, this quite likely *is not* the user's original password - there are an infinite number of plaintext inputs which will hash to any given MD5 result. And, as @David_001 said, it wouldn't be useful even if it was the user's original password. I have *never* encountered a case where there was a legitimate reason for admins to know other users' passwords.
Dave Sherohman