digplanet beta 1: Athena
Share digplanet:


Applied sciences






















In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.

A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. Hashing allows for later authentication while defending against compromise of the plaintext password in the event that the database is somehow compromised.

Cryptographic salts are broadly used in many modern computer systems, from Unix system credentials to Internet security.

Unix implementations[edit]

Earlier versions of Unix used a password file (/etc/passwd) to store the hashes of salted passwords (passwords prefixed with two-character random salts). In these older versions of Unix, the salt was also stored in the passwd file (as cleartext) together with the hash of the salted password. The password file was publicly readable for all users of the system. This was necessary so that user-privileged software tools could find user names and other information. The security of passwords is therefore protected only by the one-way functions (enciphering or hashing) used for the purpose.

Early Unix implementations limited passwords to 8 characters and used a 12-bit salt, which allowed for 4,096 possible salt values. While 12 bits was sufficient for the 1970s, by 2005 disk storage had become inexpensive; so much so that an attacker could pre-compute the hashes of millions of common passwords, including all 4,096 possible salt variations for each password, and store the precomputed values on a single hard drive. An attacker with a larger budget could build a disk farm with all 6-character passwords and the most common 7- and 8-character passwords stored in hashed form for all 4,096 possible salt values.[citation needed]

Web application implementations[edit]

It is common for a web application to store in a database the hash value of a user's password. Without a salt, a successful SQL injection attack may yield easily crackable passwords. Because many users re-use passwords for multiple sites, the use of a salt is an important component of overall web application security.[2] Some additional references for using a salt to secure password hashes in specific languages (PHP, .NET, etc.) can be found in the external links section below.


A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the hashed password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password.

To understand the difference between cracking a single password and a set of them, consider a single password file that contains hundreds of usernames and passwords. Without a salt, an attacker could compute hash(attempt[0]), and then check whether that hash appears anywhere in the file. The likelihood of a match, i.e. cracking one of the passwords with that attempt, increases with the number of passwords in the file. If salts are present, then the attacker would have to compute hash(salt[a] . attempt[0]), where "." denotes concatenation, compare against entry A, then hash(salt[b] . attempt[0]), compare against entry B, and so on. This defeats "reusing" hashes in attempts to crack multiple passwords.

Salts also combat the use of rainbow tables for cracking passwords. A rainbow table is a large list of pre-computed hashes for commonly used passwords. For a password file without salts, an attacker can go through each entry and look up the hashed password in the rainbow table. If the look-up is considerably faster than the hash function (which it often is), this will considerably speed up cracking the file. However, if the password file is salted, then the rainbow table would have to contain "salt . password" pre-hashed. If the salt is long enough and sufficiently random, this is very unlikely. Unsalted passwords chosen by humans tend to be vulnerable to dictionary attacks since they have to be both short and meaningful enough to be memorized. Even a small dictionary (or its hashed equivalent, a rainbow table) has a significant chance of cracking the most commonly used passwords. Since salts do not have to be memorized by humans they can make the size of the rainbow table required for a successful attack prohibitively large without placing a burden on the users.

More technically, salts protect against rainbow tables as they, in effect, extend the length and potentially the complexity of the password. If the rainbow tables do not have passwords matching the length (e.g. an 8-byte password, and 2-byte salt, is effectively a 10-byte password) and complexity (non-alphanumeric salt increases the complexity of strictly alphanumeric passwords) of the salted password, then the password will not be found. If found, one will have to remove the salt from the password before it can be used.

Additional benefits[edit]

The modern shadow password system, in which password hashes and other security data are stored in a non-public file, somewhat mitigates these concerns. However, they remain relevant in multi-server installations which use centralized password management systems to push passwords or password hashes to multiple systems. In such installations, the root account on each individual system may be treated as less trusted than the administrators of the centralized password system, so it remains worthwhile to ensure that the security of the password hashing algorithm, including the generation of unique salt values, is adequate.[citation needed]

Salts also make dictionary attacks and brute-force attacks for cracking large numbers of passwords much slower (but not in the case of cracking just one password). Without salts, an attacker who is cracking many passwords at the same time only needs to hash each password guess once, and compare it to all the hashes. However, with salts, each password will likely have a different salt; so each guess would have to be hashed separately and compared for each salt, which is considerably slower than only comparing.

Another (lesser) benefit of a salt is as follows: two users might choose the same string as their password, or the same user might choose to use the same password on two machines. Without a salt, this password would be stored as the same hash string in the password file. This would disclose the fact that the two accounts have the same password, allowing anyone who knows one of the account's passwords to access the other account. By salting the passwords with two random characters, even if two accounts use the same password, no one can discover this just by reading password files.

See also[edit]


  1. ^ Salts are closely related to the concept of nonce.
  2. ^ "ISC Diary – Hashing Passwords". Dshield.org. Retrieved 2011-10-15. 

External links[edit]

Original courtesy of Wikipedia: http://en.wikipedia.org/wiki/Salt_(cryptography) — Please support Wikipedia.
This page uses Creative Commons Licensed content from Wikipedia. A portion of the proceeds from advertising on Digplanet goes to supporting Wikipedia.
453 videos foundNext > 


What Is A Hash, And Why Does It Need Salt?

Steve Smith, host of your TQA Weekly, explains why hashing is important, why salt always makes it better, and other interesting facts and tips on the manner. Show Notes for this Episode http://tqa...

Salt (cryptography)

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase. The primary function of salts is to defend against dictionary...

Why Salt is good for you: Handling passwords in web applications

Jason Swearingen from Novaleaf Software describes basic web-app user account security, focused on password salting, and explains a simple yet robust implementation.

Salted Password Scheme - Applied Cryptography

This video is part of an online course, Applied Cryptography. Check out the course here: https://www.udacity.com/course/cs387.

How NOT to Store Passwords! - Computerphile

Security of users' passwords should be at the forefront of every web developer's mind. Tom takes us through the insecure ways in which some websites deal with passwords. Hashing Algorithms...

Don't encrypt passwords

Encryption passwords is bad. Try hashing them with a little bit of salt on top. Confused about the terminology - maybe i can clear your confusion with the use of a shoe, a box and a pen & paper....

PHP Tutorial: Secure Password Hashing using crypt()

In this video lesson you will learn how to securely salt and hash user passwords for safe storage in your database. We will be going over how to use the PHP crypt() function and Blowfish algorithm...

Java prog#129. How to encrypt and decrypt data in Java Part 1

Password Encryption.java JAVA ENCRYPTION/DECRYPTION PROGRAM HELP Encrypting and Decrypting Java Cryptography using Java in Netbeans IDE Cryptography using Java in Netbeans IDE ...

Kevin Hakanson - Securing TodoMVC Using the Web Cryptography API

The open source TodoMVC project implements a Todo application using popular JavaScript MV* frameworks. Some of the implementations add support for compile to JavaScript languages, module ...

453 videos foundNext > 

3 news items

Tue, 09 Oct 2012 12:34:07 -0700

One of the central problems in modern computer security is the need to protect an ever-increasing amount of user data from an enormous array of potential threats. Researchers at the security firm RSA have proposed a new method of securing passwords ...
Sun, 03 Mar 2013 03:47:03 -0800

Cloud-based note taking and archival service Evernote announced on Saturday that they had initiated a site-wide password reset after detecting suspicious activity on their network. According to Chris Davies of Slashgear, the incident is believed to be ...
Thu, 12 Jul 2012 15:19:34 -0700

Yet another web service has been compromised this morning as hackers have stolen and leaked more than 453,000 Yahoo Voices accounts and passwords. According to Ars Technica, the hackers say they retrieved the accounts and passwords from ...

Oops, we seem to be having trouble contacting Twitter

Support Wikipedia

A portion of the proceeds from advertising on Digplanet goes to supporting Wikipedia. Please add your support for Wikipedia!

Searchlight Group

Digplanet also receives support from Searchlight Group. Visit Searchlight