The importance of “salt” for passwords

Posted by

  

Because just like pasta, passwords without salt turn out badly

When it comes to password security, almost everyone knows that they should never be saved in plain text, but must be protected through hashing. However, there is a fundamental detail that is all too often overlooked or poorly implemented: the salt.
This small ingredient makes an enormous difference between an "acceptable" system and a seriously vulnerable one.

Let's see why "salt" is so important, how it should be correctly managed, and what happens when it is not used.

🔗 Like Techelopment? Check out the website for all the details!

🔡 Password Hashing: The Starting Point

An hash is the result of a cryptographic function that transforms an input (the password) into a fixed-length string.
Key characteristics of a good hashing algorithm:

  • It is deterministic: the same password always produces the same hash
  • It is one-way: you cannot retrieve the original password from the hash
  • A small variation in the input produces a completely different hash

Example (simplified):

password123 → ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

However, if two users use the same password, without salt they will obtain the same hash. And this is where the problems begin.


🧂 What is a Salt and Why It Is Truly Needed

The salt is a random string that is added to the password before hashing. 

hash = H(password + salt)

The salt:

  • Is unique for every user
  • Does not need to be secret
  • Must be sufficiently long and random

Thanks to the salt, two users with the same password will have completely different hashes.

Without Salt

User A: password123 → hash1
User B: password123 → hash1

With Salt

User A: password123 + X7f$2 → hashA
User B: password123 + 9K!pQ → hashB

Same password, totally different results.


🏴‍☠️ Real Cases: When Salt Was Missing

LinkedIn (2012)

In the famous LinkedIn data breach, over 6 million passwords were exposed.
The main problem? Passwords hashed with SHA-1 and without salt.

Result:

  • Crackers used precomputed rainbow tables
  • The most common passwords were recovered in a very short time
  • Millions of accounts compromised

RockYou (2009)

The RockYou leak contained plain text passwords, but it became a reference precisely because it allowed the creation of massive dictionaries and attack tables that are still used today against unsalted hashes.

Modern Attacks

Even today, databases with hashes without salt:

  • Allow for extremely rapid offline attacks
  • Make "decent" but common passwords useless
  • Allow correlations between users with the same password

🏴‍☠️ Salt and Rainbow Tables: The Real Enemy

Rainbow tables are precomputed tables that associate common passwords with their respective hashes.

Without Salt:

  • A single table can be used against millions of hashes
  • The attack is incredibly fast

With Salt:

  • A rainbow table would be needed for every salt
  • Computationally impractical
  • The attack essentially loses its meaning

This is one of the main reasons why a system without salt is considered insecure, even if it uses a "strong" hashing algorithm.


🧑‍🎓 How to Manage Salt Correctly

A common question is:
“If the salt is random, how do I verify the password?”

The answer is simple: the salt is saved along with the hash.

User Registration

  1. The user enters the password
  2. The system generates a random salt
  3. Calculates the hash: 
    hash = H(password + salt)
  4. Saves in the database:
    • salt
    • hash

Login / Credential Verification

  1. The user enters the password
  2. The system retrieves the salt associated with the user
  3. Recalculates: 
    verification_hash = H(entered_password + salt)
  4. Compares verification_hash with the saved hash

If they match, the password is correct.

👉 The salt must never change for that user, otherwise the resulting hash would be different.


♻️ Global Salt vs. Per-User Salt

❌ Global Salt (Not Recommended)

  • A single salt that is the same for all users
  • Better than nothing
  • But still vulnerable to various attacks

✅ Unique Per-User Salt (Best Practice)

  • Each password is isolated from others
  • No correlation between hashes
  • Maximum resistance to offline attacks

ℹ️ Salt ≠ Pepper

For completeness:

  • Salt: random, public, saved in the DB
  • Pepper: global secret, saved in the code or in a vault

Pepper can add an extra layer of security, but it never replaces the salt.


💣 The Practical Risks of Not Using Salt

Not using salt exposes you to very real risks:

  • 🔓 Massive password cracking
  • ⚡ Extremely fast offline attacks
  • 👥 Identification of users with the same password
  • 📉 Total compromise in case of a breach
  • 🧠 Immediate exploitation of common passwords

In practice, if a database is stolen:

  • Without salt → disaster
  • With salt → limited damage and much higher attack costs

🎯 Conclusion

Salt is one of those details that seem small, but separates professional security from amateur efforts.
It is not an optional extra, it is not an "advanced feature": it is an absolute necessity.

Just like in cooking:

  • A good recipe without salt is bland
  • A password system without salt is insecure

And in computer security, as in cooking, adding the salt at the right time makes all the difference.



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment