Salted Password Hashing
There are many ways in which passwords can be stored, with varying levels of security. Salted password hashing uses a non-reversible hashing algorithm with the inclusion of a randomised element to make it more difficult to obtain user passwords.
When creating software that includes a login process with a user name and password, the login credentials must be stored in some format. This information must be secured to prevent unauthorised users from finding the passwords and accessing sensitive information. Failure to protect passwords could lead to loss of credibility as a software developer, loss of money if a client decides to sue and loss of users who believe their information is insecure.
Passwords can be stored in many places, such as in files or databases. The security of the file system or database management system and any network security provide a first line of defence against malicious access. However, it is possible that these defences are overcome or that a user with access to the raw data wishes to access it improperly. The level of security of the credentials list is then determined by the format in which it is stored.
Plain Text Password Storage
The most basic way to store user credentials is using plain text. In such a scheme the login names and passwords are stored in pairs. When a user requests access to the system, the provided user name and password are compared with the list. Plain text storage is dangerous. If a malicious user obtains the credentials file, they gain access to every user account.
The table above shows the layout of a plain text credentials file. You should never use this type of storage. Even if your system does not contain sensitive data, it is likely that some users will use the same login details for other systems or web sites that do.
A second way to store credentials is to encrypt the passwords using a reversible algorithm. When a user tries to login, their user name is located in the list and the associated password is decrypted. The decrypted password is compared to that entered to determine if they are allowed access to the system. This is more secure than plain text but still has problems. If a malicious user has access to the file they may be able to reverse engineer the encryption algorithm and gain access to the entire password list.
The table above shows the previous list of users and passwords with encrypted passwords. In this case the encryption is over-simplistic but shows the problem that it is possible to find a user's password if you know the algorithm.
A third option for securing credentials is password hashing. Passwords are encrypted using a one-way algorithm that cannot easily be decrypted to find the original value. When the user logs in, the password that they provide is hashed using the same algorithm. The hashed value is then compared with the matching hash in the credentials list.
The above table shows an example set of hashed passwords. This table highlights one key problem with this method of storage. As Stephen and Sarah have used the same password they also share the same hash value. If someone were to have access to the password file they could look for groups of users with matching hash codes. This would probably indicate that those users have used real words for their passwords. This information could be used to start a dictionary attack.
Salting Hashed Passwords
The last method of storing passwords that we will consider is the salted hashed password list. The overall process is similar to hashing described above. In addition, a random value is introduced for each user. This salt value is included with the password when the hash value is calculated and is stored with the user record. Including the salt value means that two users with the same password will have different password hashes.
|User||Random Salt||Password Hash|
In the above table we have a new column storing the salt value for each user. Including the salt means that the password hashes for Stephen and Sarah are different.
6 February 2011