- The salt is a random string that is added to the password before the hash to achieve unique hashes per user.
- Linux It stores hash, salt and algorithm in /etc/shadow, strengthening security against dictionary attacks and rainbow tables.
- Good practices require long, random, and unique salts, along with robust hash algorithms and databases well protected.
- Password salting should be integrated into broader security policies that include strong passwords, MFA, and password managers.
If you work with GNU/Linux systems or are simply concerned about the security of your accounts, you've probably heard of the salt in password hashes . It's one of those concepts that's mentioned a lot, but often only partially understood: it sounds technical, but in reality, it makes the difference between a system that's easy to crack and one that's much more resistant to attacks.
In short, the salt is a key component in making password hashes unpredictable . It involves adding random data before applying the hashing algorithm so that, even if two users have the same password, the result stored in the database will be different. From there, the specific implementation in Linux, its relationship with /etc/shadow, tools like mkpasswd, and modern security best practices are a whole world in themselves, which we'll explore in detail.
What exactly is the salt in a password hash?
In cryptography, a salt is a random string of characters that is appended to a user's password before a hash function is applied. The goal is for the resulting hash to be unique even if the plaintext password is the same for multiple users.
When a user creates or changes their password, the system generates a random salt , combines it with the password (before, after, or in a specific format depending on the scheme), and applies a hash algorithm, such as SHA-256 or SHA-512 , to this combination . The database does not store the password itself, but rather the hash of (password + salt) , and in most schemes, the salt is also stored along with the hash.
This technique renders many attack techniques based on precomputed hashes , such as rainbow tables, useless, and greatly complicates large-scale dictionary and brute-force attacks. An attacker can no longer exploit the fact that multiple users share a password, because each user will have a different hash.
It's important to understand that the salt isn't a secret in itself: it's neither a password nor a private key . Its function is to introduce randomness and uniqueness into the hashing process. Security still depends on using strong passwords and appropriate hashing algorithms , preferably designed specifically for passwords (such as bcrypt, scrypt, Argon2), although many classic Linux systems use variants of SHA-256 or SHA-512.
How password salting works step by step
The salting process can be summarized in a series of fairly simple steps, but with a huge impact on security :
First, when a user registers or changes their password, the system generates a unique, random salt for that credential. This salt is usually of sufficient length (for example, 16 bytes or more) and is obtained from a cryptographically secure random number generator.
Next, the user's chosen password is combined with that salt to form an intermediate string . This combination can be as simple as concatenating salt + password, or it can have a more complex format defined by the hash scheme. The important thing is that each user ends up with a different combination.
Next, a one-way hashing algorithm is applied to that combination . The result is a seemingly random string, the hash, of fixed length, which is stored in the database along with the salt. In modern systems, algorithms that produce long and complex outputs are sought , which increases the search space and makes brute-force attacks more expensive.
Finally, when the user logs in, the system again retrieves the entered password, retrieves the associated salt from the database, repeats the exact same combining and hashing process, and compares the result with the stored hash. If they match, the system knows the password is correct without needing to see the plaintext.
This mechanism means that even if the database is leaked, the attacker will only see individual hashes with their own salts , instead of a set of comparable hashes. Stopping an attack isn't magic, but it does become significantly more computationally expensive.
Advantages of using salt in password hashes
The main reason for using salting is that it strengthens the security of stored passwords against a wide variety of attacks. But it's worth detailing the specific benefits.
First, salting provides resistance against dictionary attacks . Without salt, an attacker can prepare a huge list of common passwords and their hashes, and simply compare them to the stolen database. With a unique salt per user, those pre-calculated hashes become useless, because each password + salt combination generates a different value.
Secondly, the use of salt breaks the effectiveness of rainbow tables , which are simply pre-computed databases of hashes of popular passwords designed to speed up recovery. Again, since the outcome depends on the specific salt, these tables, intended for unsalted hashes, become useless or, at the very least, highly inefficient.
Another clear advantage is improved privacy in the event of a data breach . Even if an intruder gains access to the user table with its hash and salt, they won't be able to quickly identify who shares the same password or easily launch mass attacks. Each account requires individual attention, which is often impractical on a large scale.
Furthermore, salting adds complexity to brute-force attacks . Instead of being able to test a candidate password against all hashes at once, the attacker is forced to consider each user's salt, multiplying the total effort. If this is combined with a slow and parameterizable hashing algorithm (like bcrypt or Argon2), the attack cost increases even further.
Finally, salting is a technique that adapts well to technological evolution. Even as computing equipment improves and new attacks emerge, the combination of a robust hash and a unique salt maintains a high and scalable level of difficulty: the salt length can be increased, the algorithm strengthened, the computational cost raised, and so on.
How Linux implements password salting (/etc/shadow)
In Linux systems and other *NIX variants, user passwords are not stored in /etc/passwd, but in the /etc/shadow file . This file, accessible only to the superuser, stores password hashes along with additional information, and is where the use of salt and the hashing algorithm is clearly seen.
The lines in /etc/shadow have a structure similar to:
user:$id$sal$hash:additional_fields…
The dollar sign ($) separates the different parts. The first part after the username indicates the type of algorithm used. For example, $1$ usually represents MD5, $5$ SHA-256, and $6$ SHA-512, which is the most common algorithm in modern distributions because it offers greater security than older schemes based on DES or MD5.
After the algorithm identifier comes the salt , followed by the resulting hash . All of this is contained within the same field. When a password is validated, the system reads this identifier and the salt, applies the algorithm corresponding to the entered password, and compares the calculated hash with the stored one.
To quickly inspect which users have encrypted passwords and which algorithm is being used, you can use a command like `grep '\$' /etc/shadow` . In this context, the dollar sign ($) is used to locate lines with hashes in modern format. The symbol must be escaped with a backslash because in regular expressions it signifies the end of a line.
Passwordless or locked accounts typically display a value like ! or * in that field instead of a hash with dollar signs, indicating that authentication with a standard password is not possible. This structure makes one thing clear: Linux integrates salting into its password storage format natively.
Difference between password hashing and salting
It's important to distinguish between two concepts that are sometimes confused: hashing and salting . Password hashing is the process by which a password is transformed into an unrecognizable value using a one-way algorithm. The server never needs to know the original password, only to verify that the user knows the correct password because it produces the same hash.
The problem is that if two passwords are identical, their unsalted hashes will also be identical . This allows an attacker to compare them, group users by password, or use pre-calculated tables. Furthermore, if the hashing algorithm is fast and designed for data integrity (like simple SHA-256), it becomes more vulnerable to massive brute-force attacks.
Salting comes in precisely to solve this weakness: it involves adding random data to the password before hashing it. The result is that even if two users choose "casa" as their password, the hashes in the database will be completely different, because one will have, for example, "casa+7Ko#" and the other "casa8p?M" as the pre-hashed string.
Thus, hashing and salting do not compete, but rather complement each other. Hashing provides the property of unidirectionality and ease of verification; salting provides uniqueness and resistance against mass attacks . A secure password storage implementation combines both techniques, ideally using an algorithm designed for this purpose, with a configurable cost.
Using the salt in Linux with mkpasswd
In GNU/Linux environments and other Unix -like systems , a very practical way to experiment with password salting is with the mkpasswd tool . This command is used to generate secure , encrypted passwords and is commonly integrated into user creation processes, administration scripts, and so on.
The basic syntax of `mkpasswd` allows you to specify the password to be encrypted and a series of options such as the algorithm type (for example, `des`, `md5`, `sha-256`, `sha-512`) using the `-m` option . On modern systems, it is advisable to opt for at least SHA-512 , or for even more robust schemes if the distribution supports them.
The particularly interesting option in the context of salting is -S , which allows you to add a salt to the password before encrypting it. If not specified manually, mkpasswd can generate a random salt on each execution , so even using the same input password, the resulting hash will be different each time.
This can be easily verified: if you encrypt “password123” several times with mkpasswd, using SHA-512 and a random salt, you will obtain completely different hashes. However, if you pass the same salt value using -S, the hash will always be identical, because the password + salt combination does not change.
Thanks to this tool, it's very easy to prepare salted encrypted passwords to add to configuration files, manage users manually, or test salting behavior without having to program anything.
Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.