Salt

PHP
1

I think I am missing a fundamental concept on how to use salt along with password encryption.

I don’t understand how it is different than just encryption.

The way I understand the program flow right now is:

  • a user attempts a login
  • for example $_POST[‘password’] is run through an encryption algorithm with salt
  • that value is then compared to a hashed value stored in a database

The part that confuses me is, if every $_POST[‘password’] value for every log in attempt runs through the same encryption algorithm with the same salt string, how is using salt anymore secure?

If the salt string was “e4f20ab”
and you put the salt string in the begining of a password string before hashing, isn’t the above scenario just the same as telling your users to prefix all log in attempts with “e4f20ab”?

2

The idea is that you don’t reveal the salt to anyone. That way, they have no idea what is added to the password, making the encryption that much more difficult to figure out.

3

The idea is that it’s much less likely that a hacker will have a rainbow table on hand with all the words in the dictionary salted with your extra characters.

It’s easy to have a rainbow table with hello = 5d41402abc4b2a76b9719d911017c592, love = b5c0b187fe309af0f4d35982fd961d7e and so on, but they won’t have one ready to go with values for e4f20abhello, e4f20ablove and so on.

What’s even more secure is if you have a different salt per-user. You’d store the salt in the DB, then someone would need to build a new rainbow table for every user account.

You can do the concat in your SQL query when validating logins


$pw = mysql_real_escape_string(trim($_POST['password']));

SELECT id FROM users WHERE password = md5(concat(salt, '$pw'));
4

Cute Tink if the attacked has access to your DB to see the hashes, they will have access to the salt.

5

That would be true if the salt was stored in the database. I keep my salt-type info under the web root usually. And if someone has access to your database, then I would think that the discovery of your salt would be the least of your concerns.

6

Makes sense, I understand now thanks.

There will only be 1 login and 1 password for this application. Do you have any other suggestions to make it even more secure?

Thanks in advance.

7

One method is to concatenate the static salt with the creation timestamp for the user.

8

Wait… I’m still a little confused, I think I am confused because I don’t know how a rainbow table would be used.

I have a log in form with 2 fields, user name and password.

Right now I understand it that a hacker would manually guess my password, click submit,
the password the hacker guessed would go through my hashing algorithm, with salt, and be tested against the real hashed password in the db.

If the hacker guessed wrong, they could try another manual log in attempt.

How does a rainbow table speed up this process for a hacker? Is there a way a hacker can submit my form several times a minute automatically?

9

Irrelevant. They still can’t reverse engineer back to the original password if you do it right. vbulletin uses

md5($salt . md5($password))

The salt is unique to each user and stored into the database, so the sql query


SELECT id FROM users WHERE password = md5(concat(salt, md5('$pw')))

works.

Because of the double md5 pass you can’t get back to the original password the user gave, even if you’re the admin. That information is destroyed by the hash process - hashes are destructive of the original data.

If they compromise the database and see salts and hashes the original passwords are still safe. While it is possible to construct a rainbow table against that given salt, that would take a long time and still wouldn’t reveal the original password.

This secures passwords between vbulletin installations since the salt is randomly built at each user (let alone server). If an admin here makes an account on a board I run, I can’t use the resulting password hash to crack this site.

10

Michael, does that mean that salts purpose is to help protect plaintext passwords that have been hashed and stored in a db IF the database was hacked into?

11

Yes for this reason - people tend to use the same password on multiple unrelated sites. This isn’t safe, but it is human. Hell, I have a throw away password I use on sites that I don’t care whether or not the account is compromised, and it isn’t that strong either. The password I use on more sensitive sites (my bank) however are much stronger and unique to that account.

Face it, if your db is compromised, the safety of the data there is gone. It’s data there that can be used elsewhere that the hacker is after - such as passwords in a state that they might be able to attack important sites.

12

makes sense. so a rainbow table is only useful for a hacker that has already recovered hashed passwords from a database?

in other words, a rainbow table does not help a hacker in anyway to log in to my site via the log in form on the web?

13

If you’re salting your passwords then yes, rainbow tables are defeated by this means.

Salting

  1. Protects you, the admin, from liability in the event of database compromise.
  2. Protects the user in case they are careless about not maintaining unique passwords across multiple sites.

It’s not a new practice - dates all the way back to at least the early 70’s if not before.

Rainbow tables are only useful for attacking sites with unsalted passwords, regardless of the hash schema. Note that rainbow tables do not work against encryption.

The difference is this. An encrypted password can be recovered. There exists a 1 to 1 relationship inputs and outputs and the process is reversible if the encryption key is known. Hashes have no such recovery, there exists a many to 1 relationship between hash inputs and outputs.