1.3 Salt to protect
This section is part of the amber and green pathways.
The security of stored passwords can be increased by a process known as salting – in which a random value (called the salt) is added to the plaintext password before the hashing process.
This greatly increases the number of possible hash values for the password and means that even if two people choose identical passwords, their hashed passwords have completely different values.
The hashed password and the relevant salt are stored by the password server. When the user attempts to log in to the computer, their password and the salt are added together, hashed and compared to the stored, hashed value.
The following table illustrates two things – firstly, that adding a random salt to a user password generates a hash digest different to one without a salt; and secondly, that two users having the same password will still have different hash digests due to the different salts. You can see this by comparing the passwords and hash digests here with the table in Section 1.1.
|26FF CEBB E5F3 8BBA 646C C55F 2333 CF42
|B2E2 FC8E BBCC D7A2 FE30 CCCB 9090 F079
|May151995 - bad password
|B924 3795 3D05 A443 234B 3ED2 40C8 4299
Salting is only effective if:
- truly random salts are used for each password (some systems have either used a single salt for all passwords, or have only changed the salt when the computer is restarted)
- the salt is long enough that, when added to a password, it will create enough possible hashed values that an attacker cannot generate a table containing all possible hashes from a salted dictionary. For instance, the passwords used by UNIX in the early 1970s were restricted to eight characters and used a 12-bit salt. When released this was secure enough – it was not feasible to generate the hashes for every possible password each of which had been salted with all 4,096 possible salts. However, the rapid advance in computer power and storage capacity meant that longer salts are required. A typical piece of advice is that the salt should be the same length as the output of the hashing function – so if your hashing function generates 256-bit hashes, a different 256-bit unique salt should be used for each password.
Case study: LinkedIn
In the middle of 2012, the hugely successful social networking site LinkedIn was attacked by Russian hackers. The passwords to some 6.5 million accounts were stolen, but although they were stored as hashed values, the passwords had not been salted.
The hashing had been performed using the relatively old SHA-1 hashing algorithm which can be performed at very high speed (a desktop computer can calculate several tens of millions of SHA-1 hashes per second).
It was therefore not surprising that within a day, decrypted passwords were being published on the internet and LinkedIn was forced to ask all users to change their passwords.
Preventing the attacks described above depends on the online service taking steps to encrypt the transmission and storage of passwords. As users, we can help in this protection by choosing passwords that are difficult to attack.