The-Crucial-Role-of-Salt-in-Password-Hashing
When we create account in Gmail, Facebook or any other application (especially web-application), we set credentials (username and password). Steps are as follow
1. When we set password (like qwert123) for the first time, a secure application turns this plaintext password into a fixed-length, irreversible string set and stores in the database along with username (generally in hexadecimal number: 824a67f29e97b8798a9df7f00189f3e1).
2. After creating account, when we put username and password to login, the application turns our plaintext password into hash again.
3. Compares with previously stored hash and finally grant or reject access depending on whether there is a match or not.
An application cannot reverse this hash (824a67f29e97b8798a9df7f00189f3e1) to plaintext (qwert123), it just compares two hashes. That is, a secure application itself does not know our plaintext of password, it only stores the hash of password which is not reversible.
Converting plaintext to hash value is done by cryptographic one-way hash function. MD5, SHA-1 SHA256, SHA512 etc. are popular password hashing algorithms.
Example: Let, MD5 algorithm is applied here
H(qwert123) = 824a67f29e97b8798a9df7f00189f3e1
H(qwert124) = f8b206baad2e87685c4d2afb9fea026e
Notice that, changing only one character in input, produces completely different hash.
Now, if there is data breach where millions of user credentials are leaked, then what will happen? Can anyone/ hacker access those user accounts? In general, the answer is no, because all passwords are in hash form, not in plaintext. As hash is not reversible, i.e. hash value can not be turned into plaintext password. So, in some scenes we can think, we have ensured password security by hashing. But it is not still secure. Hacker uses a special type of plaintext to hash mapping table called rainbow table to find the plaintext password. Hacker precomputes the hashes of dictionary words, commonly used passwords and stores in rainbow table with chain.
Plaintext password, x
|
Hash value, H(x)
|
mango123#
|
c06db2202300518ffa4ba45d9e036cb4
|
P4$$w0Rd2025@!
|
713d37019f1a482c7056bab3ad409e39
|
Password123
|
42f749ade7f9e195bf475f37a44cafcb
|
123456
|
e10adc3949ba59abbe56e057f20f883e
|
987654321
|
6ebe76c9fb411be97b3b0d48b791a7c9
|
Q1w2e3r4t5
|
7487eaa30b419456547e3de70625d8b4
|
Simple rainbow table (chain is not shown here)
So, here we see that only hashing password is not enough to ensure its security, attackers use rainbow table to find plaintext password. But there is a limitation of rainbow table, it has hashes of dictionary words, commonly used passwords only. If an application appends a random string with user’s password and then converts this appended plaintext password to hash, it will be completely different and there is almost no chance to have this hash in rainbow table. This random string/ number is called salt, which makes a different taste hash. Adding salt with password is protective measure against rainbow table attack. Salt can be appended either before or after the password. But adding before is common practice.
Example: Let, MD5 algorithm is applied here and salt is of 4 characters long (For demonstration only)
H (“123” + “qwert123”) = 116c320af1ff0a656709c7f424567191; salt=123
H (“120” + “qwert124”) = 4710a61322b0170454a473a337083a54; salt=120
For every user, salt is stored in database along with hash value.
A good salt must be:
1. Unique for very user
2. Long enough compared with number of application user
3. Length will be as long as output of hash function
4. Generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)
An application developer must use salt to protect password from rainbow table attack.
.png)
.png)
Comments
Post a Comment