ermm i'm not sure you can decrypt MD5 it is one way.
You will have to use another way of storing passwords which you can decrypt, but will most likely be unsecure.
You are going to have to use password resets if they forget there passwords.
password retreive
You might not be able decrypt md5 password
You should use password resets method when user forget there password
it will be good way so as to secure password or another method is to send the active key to they mail when user click on that mail redirect him to change password page
Passwords should, generally speaking, be stored in an unencryptable format for security. It prevents people from gaining a low level of access to web-based systems and exploiting an SQL query to view all of the other passwords.
to clarify some of the previous posts, [man]md5/man is a hash, not an encoding. You cannot "decrypt" it, and you're not supposed to be able to. (Yes, collisions have been found, and there are extensive "rainbow tables" of known value=>hash pairs - but that's why other algorithms, like [man]sha1/man, are now recommended instead of md5).
to echo what Ashley said, you should never "show" a user's password. Use a reset form instead. If your system is designed properly, it should be impossible for anyone -including the to "figure out" a user's password by using the value you store in the database.
And I have to LOL knowing that some sites out there still store user passphrases in PLAINTEXT.
Not that I advocate such, of course 
dalecosp wrote:And I have to LOL knowing that some sites out there still store user passphrases in PLAINTEXT.
One way to spot them is that they have a maximum password length limit ... which I for one find is always too low.
+1 correcthorsebatterystaple!
maximum pw length doesn't prove pw is not hashed - might just be legacy codebase (mea culpa)
also there's something wrong if a password allows this:
It prevents people from gaining a low level of access to web-based systems and exploiting an SQL query to view all of the other passwords.
bradgrafelman;11002868 wrote:It gets even more saddening when you run across instances where certain characters aren't allowed in your password in addition to the max limit.
During my time of unemployment I was signing up to a job search website and they wouldn't allow the @ symbol (they banned a few other symbols as well). Thankfully I didn't do much with that site and I removed my account shortly after I landed a job elsewhere.
bradgrafelman;11002833 wrote:Actually, if you care about how "broken" your hashing algorithm is, you really shouldn't use SHA-1 either - stick to something like SHA-256 instead.
Is there any real reason to use an algorithm like SHA-256 over SHA-384 or SHA-512. The only things I can think of are size and speed, but we're talking bytes and milliseconds here. I just ask because I see SHA-256 recommended a lot (here and elsewhere) but never SHA-384 or SHA-512.
Bonesnap wrote:Is there any real reason to use an algorithm like SHA-256 over SHA-384 or SHA-512. The only things I can think of are size and speed, but we're talking bytes and milliseconds here.
I think that is really up to you to decide how much space you want to allot for this. Even old MD5 is still not broken for preimage attacks, so it is more important to use a user-specific salt of sufficient length than it is to choose SHA-512 over SHA-1. I would say that MD5 with such a salt and key stretching provides a far better margin of security than plain SHA-512.
laserlight;11002922 wrote:I think that is really up to you to decide how much space you want to allot for this. Even old MD5 is still not broken for preimage attacks, so it is more important to use a user-specific salt of sufficient length than it is to choose SHA-512 over SHA-1. I would say that MD5 with such a salt and key stretching provides a far better margin of security than plain SHA-512.
Oh, for sure, I'd always use a salt regardless of the algorithm. I was just curious why one would use SHA-256 over SHA-512.
Bonesnap;11002952 wrote:Oh, for sure, I'd always use a salt regardless of the algorithm. I was just curious why one would use SHA-256 over SHA-512.
I'm not sure of course, but I think the only reason to use 256 over 512 is for spacial reasons. 512 is 128 characters in length versus 64 for 256. However this seems like a poor reason to choose it IMO, because disk space is stupidly cheap. As far as speed goes, the difference seems almost negligible.
<?php
$times = array();
$times[256] = array();
$times[512] = array();
for( $i=0; $i<1000; $i++ ) {
$stime = microtime(TRUE);
hash('sha256','MySuperSecretPassword');
$times[256][] = microtime(TRUE) - $stime;
$stime = microtime(TRUE);
hash('sha512','MySuperSecretPassword');
$times[512][] = microtime(TRUE) - $stime;
}
printf("<pre>sha256\n\tMax:\t%f\n\tMin:\t%f\n\tMedian:\t%f\n\tAvg:\t%f\n\nsha512\n\tMax:\t%f\n\tMin:\t%f\n\tMedian:\t%f\n\tAvg:\t%f</pre>",
max($times[256]), min($times[256]), median($times[256]), (array_sum($times[256])/1000),
max($times[512]), min($times[512]), median($times[512]), (array_sum($times[512])/1000) );
function median(Array $arr) {
sort($arr);
$cnt = count($arr);
if( $cnt%2 != 0 ) {
return $arr[floor($cnt/2)];
} else {
return ( ( $arr[$cnt/2] + $arr[($cnt/2)-1] ) / 2 );
}
}sha256
Max: 0.000023
Min: 0.000004
Median: 0.000006
Avg: 0.000006
sha512
Max: 0.000033
Min: 0.000004
Median: 0.000007
Avg: 0.000007Derokorian wrote:I think the only reason to use 256 over 512 is for spacial reasons. 512 is 128 characters in length versus 64 for 256. However this seems like a poor reason to choose it IMO, because disk space is stupidly cheap. As far as speed goes, the difference seems almost negligible.
Well, the increased space requirement and slightly slower speed are theoretical advantages of SHA-512. On the other hand, with key stretching you can slow it down far more, and although space is cheap, why use more space if it does not actually increase your practical margin of security? In this sense, I can see why SHA-256 is a sensible choice.