Rainbow Tables & Why To Add Salt
Tags: security, webdev, javascript
Published: 2020-08-12 22:16:48


Ensuring that you're encrypting your secure or private information is almost a Sisyphean task, the code might have been brought up to security standards last year, but in that time hacking has also improved. This goes double for user's passwords, as that can lead to leaking of all sorts of information.

Lets break down some of the key components you should be looking at, and why you should be adding salt to all your encryption.


##Most Passwords Aren't Very Unique 
There's a lot of passwords that are used more often than others. This could be common names, sport teams, and dates. Hackers could just have a dictionary list of words that it loops through trying to get in by brute force. Even when numbers are added to a password, they aren't always that unique.

Think of someone using their birthday in the format mm/dd as part of their password. It is 4 numbers, but instead of having 4 numbers 0001-9999, it is really only hitting 01-12 and then 01-31. Much less diverse. Much less unique. This narrows down the numbers needed to try when attempting to hack an application by brute force. 

Additionally if your site tells you specifically the password requirements, the the hacker can also narrow down to exactly what they should and shouldn't be trying. In the below pattern, if it is spelled out for the user to see, they would know that the password has to be at least 8 characters, so don't have to guess anything under than amount.

```
PassPattern: /^([a-zA-Z0-9]{8,16}$/,
```

Attacks on passwords that have been encrypted require the real-time computation of the hash. An attacker might have stolen the hashed passwords from a database, but they still need to do the computation to see if any of the passwords they are guessing match the hashed ones in the stolen database. A good password hash function is purposefully slow, meaning this would take a lot of time which isn't what a hacker wants. To avoid this situation, the attacker could try and use a rainbow table instead of using brute force.


##Rainbow Table

A Rainbow Table is a database of hashes that have already had this time consuming computation done on them. So that if your password is "GoCubs1993", "password123" or any number of normal phrase combinations, it probably already has been mapped and stored into that table. 

Random phrases and dictionaries are run through a selected hash function like SHA-224, SHA-256, MD4, & MD5. The hash mapping is then stored in a reainbow table that the attacker can do a reverse lookup on with the hashes from the stolen password database.

In this way the hackers don't have to do all the time consuming computation to steal the passwords, they just need to look for matches.

##Salt (and maybe Pepper!)
Adding a salt to the hashing process is a great way to force the hash to be more unique, complex, and increase it's security without giving extra requirements to a user. The salt is usually stored with the password string in the database. Adding salt can help to mitigate password attacks, like rainbow tables, because it will be encrypting the user's password with a random string that wouldn't be naturally included in any rainbow table. 


```
this.userpassword = "password123";
this.salt = "eyeLUV2beeSecure";
newEncryption = md5(this.userpassword + this.salt);

```

In the above example, while the password "password123" is not very unique, adding the salt to it makes "password123eyeLUV2beeSecure" is highly unlikely to be a password that would show up in a rainbow table already. This means that hackers would  need to do all the costly the computation themselves. 

You can also add pepper to extra secure your data from this sort of attack. The difference between salt and pepper is that pepper is a site-wide static value that is kept a secret and not stored in the database. It is oftentimes hard coded into the application's actual source code. It's main added use is that since it isn't store in the database, if there was a large scale compromise of the database, the application's password table containing the hashes wouldn't be able to be brute forced as the pepper was still a secret.


##What you should be using to do the encryption?
You shouldn't be [using MD5](https://stackoverflow.com/questions/2948156/algorithm-complexity-security-md5-or-sha1#:~:text=First%20of%20all%2C%20MD5%20is,SHA1%20has%20160%2Dbit%20output.) or [using SH-1](https://shattered.io/static/shattered.pdf). These don't have the needed level of security anymore, according to Fortify. You should be switching to one of the newer versions like SHA-224, SHA-256, SHA-384, SHA-512, or SHA-3. 

If you want additional information on hashing, salt, and encryption [this is a great resource](https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/).