Well first the type of encryption would be a very important piece of information.

But before you go posting that, most encryptions were intended to not be broken. And for the ones that someone did figure out there are some great tricks for hiding the actual password even then.

For the most part if the password field in the database doesn't say "unclebob1" you have very little chance of finding out what it is.

You have to realize people use he same password for everything like there email or their online bank statements and in all reality it is best to keep that data away from our eyes. Even the most honest amongst us may get tempted otherwise.

May I ask why you would need to read there passwords? Maybe that answer will have a solution for you.

    For the most part, passwords stored in a database aren't encrypted, they're hashed: the difference being that an encryption algorithm is designed to be reversible (so that encrypted data can be decrypted) while a hash is deliberately designed not to be (once the data is encrypted there is no feasible mechanism for decrypting it).

      actually we are transfer our data from mysql to sql server. so there is many account holder already exist with their user name and password. i want to enter same password in sql server. that's why i need to decrypt that passwords

        Then why do you need to know the original password? Just copy the hashed/encrypted values and insert them as they are.

        Your applications shouldn't know the difference - they'll do their own hashing/decrypting to verify the passwords.

          I am assuming you are still going access the database using PHP. If so you can leave them encryped (or hashed) and they will still be able to login.

          $newpass = sha1($postpass);
          

          You then can compare the hash (encryption) against the one in the database. Obviously if it is different type of encryption you will have to use that type. So leave them encrypted and just compare the encrypted submitted password against the one in the database.

          EDIT
          Looks like somone beat me to posting the suggestion

            i am using md5() for encryption. so please any idea to decrypt md5() encrypted passwords in php.

              md5() is not an encryption method; it's a hashing method (a very, very weak one - it's been denounced for some time now).

                waqasahmed996;10901488 wrote:

                i am using md5() for encryption. so please any idea to decrypt md5() encrypted passwords in php.

                $5 wrench will do it :-)

                  bradgrafelman wrote:

                  a very, very weak one - it's been denounced for some time now

                  That is a little of an exaggeration though since MD5 is still not broken for pre-image attacks. The problem is that when used as-is, it is vulnerable to precomputation attacks since the message digests can be computed relatively quickly.

                    First we tell him he can't decrypt(unhash) passwords. And then we tell him the md5 password hashing sucks, get a different one. Which to do that efficiently requires decrypting(unhashing) all the passwords he currently has stored.

                    Not to knock you guy's but let's give him a solution not make him throw in the towel.

                    For comparing MD5 passwords it is the same as the sha1 example I gave above.

                    $newpass = md5($postpass);
                    

                    Then just get the passwords from the database and see if they match.

                    As for maybe upgrading the hash technology you use I have never had to do it so lets see what the other guys come up with.

                      Krik wrote:

                      As for maybe upgrading the hash technology you use I have never had to do it so lets see what the other guys come up with.

                      One way to make precomputation attacks much less useful could be used in conjunction with what waqasahmed996 has now. Add a user specific salt, then hash the salt and the currently stored password hash. To check the passwords, compute:

                      if ($stored_password == md5($salt . md5($given_password)))
                        laserlight wrote:

                        The problem is that when used as-is, it is vulnerable to precomputation attacks since the message digests can be computed relatively quickly.

                        And the utility of that approach comes down to the fact that people generally pick poor passwords (I kid you not, I can recognise some MD5'd passwords by eye these days I've seen them used so often). And THAT vulnerability is something that no hash algorithm can fix.

                          Krik wrote:

                          As for maybe upgrading the hash technology you use I have never had to do it so lets see what the other guys come up with.

                          I did. It necessarily took some time and it may not be suitable depending on the user base, but we switched from MD5 to SHA-256.

                          When a user logged in we looked to see if they had a SHA-256-based hash. If they did we used it. Otherwise, we tested their submitted password against the MD5-based one. If that succeeded, we created a SHA-256 hash for them (since we now had the plaintext password to do it with). After a sufficiently long time we were able to discard the MD5 hashes.

                            i dont know why but it is not working when same encrypted password is paste on other database. i am trying to find out why it is not working. As i come to know i will post message. but please if you how to decrypt md5() then guide me.

                              waqasahmed996 wrote:

                              i dont know why but it is not working when same encrypted password is paste on other database. i am trying to find out why it is not working.

                              How does it not work? Just to check: you are using PHP's md5() function, not the database engine's MD5 implementation, right?

                                Better yet, can you show us how you're attempting to check passwords?

                                Also, since you're using MD5 currently, you know that the hexadecimal hash string with be 32 characters in length. As such, how did you store the passwords in the new database? Is it a VARCHAR(32) column or...?

                                  Weedpacket;10901504 wrote:

                                  I did. It necessarily took some time and it may not be suitable depending on the user base, but we switched from MD5 to SHA-256.

                                  When a user logged in we looked to see if they had a SHA-256-based hash. If they did we used it. Otherwise, we tested their submitted password against the MD5-based one. If that succeeded, we created a SHA-256 hash for them (since we now had the plaintext password to do it with). After a sufficiently long time we were able to discard the MD5 hashes.

                                  Yea that is about what i was thinking would have to be done.

                                    Write a Reply...