While teaching, I came across this interesting question: how useful is salting in password hashing? The exact question was, to make storing of NRICs more secure, would it help if we salted the NRICs before storing them in the database?
Let me explain.
How salt works?
Salting is a technique used to make password hashing more secure. It involves adding random data to the password before hashing it. This random data is called a salt.
Initially, if we hash the password, so SHA3(x). So if we precompute the hash of all possible passwords, we would get something like
| x | sha3(x) |
|---|---|
| a | 25125893174901 |
| b | 82515193762375 |
| c | 98729871542735 |
| d | 97101498756246 |
| … | … |
| xxx | 79827014528891 |
| … | … |
| zzz | 07928972174107 |
Now with salt, we’re adding random chars to x so the hash becomes SHA3(x + salt).
This salt is stored but not public, it’s usually stored with the hash (intuitively if you have a safer place to store the salt, u shd put the hash in there too right?).
In the case where there is a data breach and the hash is leaked, the salt should be leaked too.
So when exactly is salt useful?
For instance, you find someone’s hashed password is 25125893174901. You can just look up the hash table you precomputed and find out the password is ‘a’.
However, if the password is salted, then it wouldn’t be in this table. You have to then precompute all the sha3(x + salt) for all possible salts.
If the password is already long enough, there's not much need to salt it.
Looking back at the NRIC example, the NRIC is already short, so the amount of time we need to precompute the table for SHA3(NRIC + salt) is not that much.