It might be okay if your favourite website gets breached
2025-07-15
If you've found out that your favourite website (or any website you use!) has been breached, here's why you might not need to worry that your password is now public knowledge.
The reason for this is a technique called salting, but before we talk about it, we need to understand ways that you might implement authentication.
The simplest way might be to have a database of users that simply stores each username and password pair in plaintext. When a user wants to log in, we just compare the entered password and the password in our database. This is a bad idea, if this database gets leaked in a breach, anyone can log in as any of the users, since all of the passwords are immediately available.
Another way of implementing authentication is to make use of a cryptographic hash function. A cryptographic hash function H has special properties, but the one we care about is that they are effectively irreversible: given a hash of a string, say H(P), it is next to impossible to recover P. This means that if our database gets leaked, the attackers can't see the user's passwords, and thus can't immediately log in as them. So instead of storing the plaintext username/password pair (U, P), we can store (U, H(P)) instead.
However, there are still some issues with this approach. For example, what if the attacker precomputes the hashes of a load of passwords? Then, they can compare the hashes in our leaked database to their precomputed hashes to find a password match. This is effectively what a 'rainbow table' attack is. Secondly, because hashes are deterministic, if two password hashes match, they almost certainly come from the same password. If an attacker sees that a lot of password hashes match, they might guess it is a common password, e.g. 'password'.
Now, we can talk about how salting mitigates these two issues.
Most modern cryptographic hash functions allow you to pass an additional salt parameter to the hash function, which will then combine the salt with the input string in some way when combining the hash (a simple, but insecure way of doing this would be to just concatenate the salt to the end of the input string).
Now when a user registers we also generate a globally unique 'salt' value S (typically, we might do this by generating a cryptographically random large number of bytes) and then storing in our database (U, H(P, S), S).
So, we hash the password with the salt and store the salt in plaintext (it does not need to be kept a secret!). Then, when a user logs in, we can simply lookup our salt, compute the hash of the entered password and the retrieved salt, and see if it matches our database entry.
Since the salt is globally unique, the combination of P and S is globally unique, so it is basically impossible for an attacker to have precomputed the hash, which mitigates the rainbow table attack. Secondly, since we now generate a different hash for each user, hashes of the same password will no longer match, which mitigates the second issue.
It is important that the salt value that gets used is globally unique, i.e. unique among every database. A common mistake is to use the username as the salt since it is unique within the database. But if two systems both use the username as a salt, and one person uses the same username and password on both systems will then both hashes will be the same.
Of course, for best security practice, you should change your password on a website whenever it gets breached, and anywhere else you use that password (which should be nowhere! Get a password manager!)