I needed to reset a forgotten administrator password for a Simple Machines Forum (SMF) forum running SMF 2.0.10 today. To do so, since phpMyAdmin was installed on the server hosting the forum, I used phpMyAdmin to access the database for the forum and then found the entry in the _members table for the administrator account. I saw the following fields for the password (actual values not shown):
| Column | Type | Function | Null | Value |
|---|---|---|---|---|
| password | varchar(64) | d2d0b6f8f5e59d26550054b2f08bc7ceb514992b | ||
| password_salt | varchar(255) | f284 |
I replaced the value in the password field with a new password and deleted the contents of the password_salt field and then clicked on the Go button to update the record in the table for the administrator account.
After I logged into the forum with the administrator account, I checked the record in the table in the database for the forum again and found that there was a new value in the passwd_salt field and the entry in the password field was re-encrypted and was now a long sequence of digits and characters again rather than the plain text password I entered
A password salt is "random data that is used as an additional input to a one-way function that hashes a password or passphrase. The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks." By not storing a password in a database in plain text, even if someone gains unauthorized access to the database, even if they can then view passwords stored in the database, they can't see the actual password used for the account associated with the password. If the password was simply stored in an encrypted form, if the attacker who gained access to the database had access to a "rainbow table", i.e., a table that matched the plain text version of a password with its encrypted form, he could deduce the orginal password. But by using a random "salt" value as part of the encrypted password generation, a rainbow table won't help the attacker, since even if Sam and Sally both use the same password and the same encryption function is used to generate the stored password for both of them, because the random salt value is used as part of the process to obtain the encrypted version of the password, the value stored in the password for Sally wil not match that for Sam. So an attacker can't look up an encrypted entry in a rainbow table and find a match for the unencrypted password used to create the encrypted version and won't even know that Sam and Sally have the same password. This helps protect Sam and Sally, even if all of their data on the site where the database is stored is compromised, since the malefactor doesn't get a password for them that they might have used on other sites as well.
References:
