Or change it to the same value in your user profile (using phpMyAdmin, command line, etc). That way you don't have to convert it first and for any type of backend software that isn't using what you expect (MD5, for example) the password will always work.
Actually coop, it took me a couple of readings to follow that, but I'm not fully awake yet.
So to put it another way... you mean for him to go into phpMyAdmin, find his own account for which he already knows the password, grab the MD5 hash of his password and, still in phpMyAdmin, paste that into the super user account.
Most of the moves are for political reasons, imagine that. For example, back in 2006 NIST released this Policy on Hash Functions [csrc.nist.gov]. But most of the hoopla and discussion is centered around documents released in 2008, particularly
FIPS 180-3 Secure Hash Standard (SHS)
FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC)
The hash ("encrypted") value of a password merely masks the plain text version in some form or another. Once a person has gained access to the files, they already have everything they need, on that particular site anyway. The reasoning given for some of this is that in the event somebody has this much information and is able to reverse engineer the password, now they have the plain text version along with other details of a user including name, address, username, etc. This information could be used on other sites that the user visits or uses such as online banking perhaps. You start to get the picture.
The problem that content management systems are running into is cross-application security. If one CMS changes it's hashing mechanism, but another does not, the single-sign-on feature breaks.