What Salting Has to Do with Password Security
What Salting Has to Do with Password Security
Passwords may not be the strongest security system, but experts are constantly hard at work making them the best they can be. One product of these efforts is a process intended to fight more technologically complex methods of attack. This process is known as “hashing and salting” passwords.
It sounds like those words belong in a kitchen, but over the years they’ve found a home in security. But let’s take a step back and determine the core principles upon which this process relies.
Plain-Text Passwords
On the surface, it seems like a computer needs to know the password for the password to function. When a user enters their password into the appropriate text field, the computer can check the entry against an internal table of usernames and passwords. If the username and password match the credentials stored in the table, the user gains access to the account. This is referred to as a plain-text table, and it might look something like this:
| Username | Password |
|---|---|
| jsmith | donthackme360 |
| hsipson | greendragon27 |
| ksarsgard | 101ilovebuscuits |
| arainier | Queenofnerds33? |
Unfortunately, there is a clear problem with plain-text password storage. If an attacker gets access to the passwords, that attacker has immediate access to every account on it. It is for this reason that the first step of the process, hashing, was developed.
Hashing
The process of hashing is intended to thwart attackers who get access to a password table. Hashing is the process of storing passwords as gibberish text in the hopes that attackers can’t turn the text back into the original password. A hashed password table might look like this:
| Username | Hashed Password |
|---|---|
| jsmith | 4uy98nr7yt87934a7247cv783ncrh0jcnh87nmeu |
| hsipson | 48un5t5437nmxtvc89543tyu5849tnmx543trn54 |
| ksarsgard | 48mcxrula89utnheiid29des0s0902kmsehfrke39 |
| arainier | Ncf678ijxuh8954u8re9e84ryhmjuse387yura9gh4? |
If the user “jsmith” enters “donthackme360” into the password field, the computer produces “4uy98nr7yt879347247cv783ncrhujcnh87nmeu” after running the entered password through a mathematical function. The computer then compares the hashed password to the hashed password stored in the database. At no point does the computer store the plain-text password on a permanent table.
The mathematical function used to hash the password functions only one way. If the function were reversible, it would be trivial for attackers to take the hashed passwords off the table and turn them back into plain-text passwords. If an attacker tried to enter a hashed password into the password text field, it would be put through the same hash function and produce a completely different result, resulting in the login attempt getting denied.
However, there are limits to what a hashing can protect on its own. An attacker presented with a hashed password table can begin brute-force or dictionary attacks to attempt to gain entry.
Brute Force
A brute-force attack happens when an attacker produces random or semi-random output. That output is entered into the hash function until it produces a match. When that match occurs, the attacker has discovered the plain-text password via trial-and-error. However, this process takes time and attackers generally prefer more sophisticated methods.
Dictionary
Dictionary attacks rely on a similar principle. Like brute-force attacks, dictionary attacks enter data into the hash function at high speed until a match is found. However, they enter real words, l33tspeak, common numeric sequences, and common symbols instead of guessing at random. Advanced attackers can use statistics to dramatically decrease the time it takes until they guess the correct password, often relying on data collected from prior breaches. This attack method takes advantage of convenience-seeking user behavior to produce correct passwords efficiently.
Rainbow Tables
Don’t let the bubbly name fool you. Rainbow tables represent an upgrade to attack methodology. These massive tables contain hash values that are already matched to countless possible passwords. By pre-computing this data, attackers dramatically reduce the time it takes to identify and reverse-engineer a hash function.
Rainbow tables inflict a strain on the attacker’s resources. Because rainbow tables only work when they have a massive amount of data to work with, and that data must be stored somewhere, attackers using rainbow tables must have a large amount of storage space. As technology improves and data storage becomes more accessible, rainbow tables will see increased use in cybercrime.
Salting
Fortunately, security experts are on the case. Salting is the practice of adding additional gibberish text to the password. This text should be as random as possible. The salt is stored in plain text on the hashed passwords, which would make it look something like this:
| Username | Salt | Hashed and Salted Password |
|---|---|---|
| jsmith | 5tc9ou0 | 98uj058u9j0389u73n75v7b2nc9842c8x39c87402nicnc2a10 |
| hsipson | 8yn7u4 | 9m40765nbs389c5nv572m00203n8u7nbc82095blap3984u |
| ksarsgard | 89mu23 | 82943n5786498nb890093n84757v4019n4875nm08nm1cx |
| arainier | Xm01nv | 765ycnm3c3m901n4v58n1e0jnr7845n7m918nr492hf02394? |
The salt is added to the beginning or end of the password before hashing it. Let’s take jsmith’s password, “donthackme360” and salt it. The result (before hashing) would be:
5tc9ou0donthackme360
Feeding this into the hash function produces a much longer, much more difficult to reverse-engineer hashed password. In this case, it produced
98uj058u9j0389u73n75v7b2nc9842c8x39c87402nicnc2a10.
The perceptive among you might also notice that the passwords here are completely different than they were before, despite a sizable chunk of the true password remaining the same as it did pre-salting. Salting makes the original hashed password unrecognizable and unique. Because each salted hash must be individually pre-computed, the resource requirements needed to run rainbow tables become more demanding. Furthermore, a successful attacker could access only one account. The damage they are capable of is much more limited than the total breach resulting from any other method.
Passwords should always have salts unique to them. Using the same salt for multiple passwords, even passwords used by the same user, enables the attacker to breach multiple accounts as soon as the hash is computed.
If each password is given a unique salt, even redundant passwords look completely different on the password table. Say two users (or one user with multiple accounts) chose the password “donthackme360” on a system that only hashed passwords without salting them. The hashed passwords would be identical gibberish, giving attackers a massive clue. If the passwords are properly salted, they both produce equally distinct results on the table. Compare and contrast in the bullets below:
| Username | Password* | Salt | Hashed Password |
|---|---|---|---|
| jsmith | donthackme360 | - | 4uy98nr7yt87934a7247cv783ncrh0jcnh87nmeu |
| hsipson | donthackme360 | - | 4uy98nr7yt87934a7247cv783ncrh0jcnh87nmeu |
| ksarsgard | donthackme360 | 89mu23 | 98uj058u9j0389u73n75v7b2nc9842c8x39c87402nicnc2a10 |
| arainier | donthackme360 | Xm01nv | 8nq3v48b71n89b4n5vyt7nh0s8974bryv9w8jsjcikj87hyt7vn? |
*passwords are displayed here for example purposes and would not be stored in plain text in the hashed passwords.
When Hashing and Salting Matters
Hashing and salting matter in the same circumstances that password strength does: when attackers have access to stored passwords or a password policy does not impose a maximum limit on the number of guesses a user (or attacker) can enter. It does not protect against phishing, or spoofing, or any other attack method that relies on tricking users into voluntarily giving up their passwords. Those attacks can only be thwarted by educating users about the dangers.
Protecting yourself against brute force, dictionary, and rainbow table attacks is important, but even the best security mechanisms aren’t flawless. Quickly identifying and responding to threats is just as important as preventing them. Determining which accounts are breached is difficult, and sometimes enterprises aren’t aware of breaches until the data is sold. Automation can help with security assessments capable of identifying breached accounts, a big improvement over manually checking. Sign up for your free Voleer account run to a security assessment today!
More posts about Security
