Passwords stored in the database are simply the MD5 of the plaintext password, as shown by the following code from wp-includes/functions.php:161
function user_pass_ok($user_login,$user_pass) {
...
return (md5($user_pass) == $userdata->user_pass);
}
If an attacker can gain read-only access to the password database, such as through SQL injection, timing attacks or local compromise, this construction is insecure. The conventional defence against these attacks is salting, as used in the Unix /etc/passwd file.
Unsalted passwords are vulnerable to a number of attacks. A dictionary attack can be applied against all users simulataneously, whereas with salting, each user has to be attacked separately. Also, pre-computed tables can be used to crack unsalted passwords almost instantaneously. Time-space tradeoff attacks, such as those used by RainbowCrack are capable of breaking passwords not vulnerable to dictionary attacks.
Salting effectively defeats these attacks, at almost no cost.
The current contents of wp_users.user_pass are 32 characters in the range [0-9a-f] so a prefix character outside of this could be used to indicate that salting is used. This would allow both schemes to co-exist.
