Why use password salt?

[floridaflatlander]

I'm still trying to figure out why I should use salt.

 

If the bad guy knows a name and tries something like brute force shoving passwords into the log-in form until one worked how would salt help stop that?

 

If a bad guy, God forbid, gets hold of the user names and passwords like they did phpbb(?) forums several years ago how would salt stop that?

 

I know I may be beating this issue to death but if I have salt in the users table assigned to a user and his password now equals $stored_password = sha1($salt.$password) does this really doesn't matter? Because if the bad guy knows the user name and uses brute force or has a list of passwords from the users table that he has gotten some way. All he has to do is type in the user name and password and salt will be added automatically.

[cypher86]

you use salt in order to make more diffcult bruteforcing your password.

 

imagine a uset set password ad his/her password.

if you put at the beginning or at the end a salt like 0tds2 the resulting password will be 0tds2password which is much more complex to bruteforce.

[floridaflatlander]

if I have salt in the users table assigned to a user and his password now equals $stored_password = sha1($salt.$password).....

 

Step 1. Jo bob signs in using his name (Jo bob) and password.

Step 2. Select query1 finds the name Jo bob in the user table and retrieves the salt

Step 3. Select query2 uses name = Jo bob and adds salt & password to get $stored_password = sha1($salt.$password) to sees if user exist.

 

Maybe I don't know what brutt force is but like I said if they know a name, in theory they can just keep trying passwords until one worked. Having salt wouldn't matter.

[shlumph]

Salt helps when your database has been compromised, aka, the "bad guy" gets a hold of all the data in your user table.  Having the passwords hashed with salt will make it more difficult to find out the true passwords from the hashes.

[xyph]

You should read the article in my signature. Explains everything.

[Pikachu2000]

you use salt in order to make more diffcult bruteforcing your password.

 

imagine a uset set password ad his/her password.

if you put at the beginning or at the end a salt like 0tds2 the resulting password will be 0tds2password which is much more complex to bruteforce.

 

That isn't a salt, in the true sense of "salting" a password. That's just extra characters in the user's password. A salt is added programatically and hashed with the password, or separately then concatenated and rehashed, or possibly a substring of it is used, etc.  Salting does nothing to stop brute force attacks. You have to code protection such as a login processing delay that would make brute force attacks impractical, and/or a maximum number of failed login attempts causing account lockout. Salting a password makes it much more difficult to get any usable information by using rainbow tables against a list of hashed values.

[cypher86]

you use salt in order to make more diffcult bruteforcing your password.

 

imagine a uset set password ad his/her password.

if you put at the beginning or at the end a salt like 0tds2 the resulting password will be 0tds2password which is much more complex to bruteforce.

 

That isn't a salt, in the true sense of "salting" a password. That's just extra characters in the user's password. A salt is added programatically and hashed with the password, or separately then concatenated and rehashed, or possibly a substring of it is used, etc.  Salting does nothing to stop brute force attacks. You have to code protection such as a login processing delay that would make brute force attacks impractical, and/or a maximum number of failed login attempts causing account lockout. Salting a password makes it much more difficult to get any usable information by using rainbow tables against a list of hashed values.

 

in fact i said " complex to bruteforce". anyway i think we made the point.

[xyph]

@ Pikachu2000

 

From what I understand, salting is also method of brute force protection. It has no effect on someone brute forcing a log-in form - this is something your script needs to protect from. It, instead, comes into effect when you actual password hash is compromised.

 

Rainbow tables were kind of a flash in the pan, though they made it VERY clear that md5('passphrase') is not enough on it's own. Now, attack methods are taking advantage of graphic cards' architecture to hash at unbelievable rates - combine that with the ability to rent that speed for cheap, and brute forcing becomes plausible. Salting, in this case, increases the size of the password being hashed and makes brute forcing much more difficult.

 

Now the only concern is if your salt is compromised - This is where something like HMAC comes in. Simplified, what HMAC does is iterate the hash function thousands of times to get a final hash, applying a salt through the entire process. This means every attempt will take thousands of times longer than a single hash.

 

This adds TONS of overhead to the server though. Thankfully, it's only during log-in or user creation. It does make DDOS attacks slightly easier - distributed continual requests to a login page with bogus data could bring your server to it's knees. DDOS attacks are fairly straightforward to deal with though, and unless you're hosting your own server, isn't something you have to worry about.

 

Again, there's a lot more to read in the article in my sig

[Psycho]

Here is a real-world example.

 

Let's say you don't salt your passwords and a user, unfortunately, uses a simple password, such as "password". That person's MD5 has would be: 5f4dcc3b5aa765d61d8327deb882cf99

 

There are people who have constructed massive tables of the MD5 hashes for known values. So, they could simply go here (http://md5decryption.com/) and enter the hash to find the value. Although there are an infinite number of values that could create that hash, there is a finite list of strings that can be passwords which is why this works.

 

If you use a salt, then the "bad guy" would need to know the salt and the hashed value. Then he can create a script to start going through the massive list of potential passwords in order to find a match (brute force). When doing this the person would start with normal "words". That is why you should always use complex passwords. Even if your hash and salt were compromised it could take a long time to find the correct hash. This is also why you would want to use a different salt for each user. That way the "bad guys" couldn't create a new rainbow table to use against all the users' hashes. They would have to brute for each and every hash separately.

[floridaflatlander]

Salting a password makes it much more difficult to get any usable information by using rainbow tables against a list of hashed values.

 

 

So salt helps protect against a list of hashed values from a (or my) users table? And if thats true that means the bad guy must first get this list of hashed values in the users table?

[joe92]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

[floridaflatlander]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

 

LOL they're already there, AKA inside.

[shlumph]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

 

LOL they're already there, AKA inside.

 

Most people use the same passwords for other sites.  Online banking, financial services, facebook, etc.  And if not the same, only a small change.  This would be the reason why the hacker would want this information.

[ManiacDan]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

Having your own database breached is generally a bad thing, but if your database security is so poor that you end up revealing your user's plaintext passwords (which they might use for online banking or email) then you have a whole other problem.  You have to contact all your users (if you can) and tell them to change all their passwords everywhere else on the internet (assuming they use the same password for everything).  You might be on the hook for any financial damages incurred due to your poor security (depending on the jurisdiction) and you'll certainly lose a lot more customers than if you had simply lost their order history but their passwords were safe.

 

Everyone read the article in xyph's sig, it really is good.

[floridaflatlander]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

if your database security is so poor that you end up revealing your user's plaintext passwords

 

I hoped they're hashed.

 

Most people use the same passwords for other sites.  Online banking, financial services, facebook, etc.  And if not the same, only a small change.  This would be the reason why the hacker would want this information.

 

True, but they first must get it

 

 

[joe92]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

Having your own database breached is generally a bad thing, but if your database security is so poor that you end up revealing your user's plaintext passwords (which they might use for online banking or email) then you have a whole other problem.

 

Yup, I was merely making a joke. I would never actually advise any one to not salt passwords It's very basic security and it's not hard to implement.

[ManiacDan]

The ironic thing is though, if your database has been compromised I think the least of your worries is the hacker getting a hold of your users passwords

if your database security is so poor that you end up revealing your user's plaintext passwords

 

I hoped they're hashed.

 

Most people use the same passwords for other sites.  Online banking, financial services, facebook, etc.  And if not the same, only a small change.  This would be the reason why the hacker would want this information.

 

True, but they first must get it

I still don't think you're quite understanding what we're saying:  If you don't salt your passwords, and someone gets your database, then they WILL HAVE the user's plaintext passwords, either eventually or immediately through rainbow table attacks.  Ok, read that again.  If they have your database and your passwords are not salted, they will get the plaintext passwords out of it.  Get it?  Good.  Salting your passwords properly prevents someone who has a copy of your database from translating the hashed passwords back into plaintext so they can be used on other sites.

[floridaflatlander]

Salting your passwords properly prevents someone who has a copy of your database from translating the hashed passwords back into plaintext so they can be used on other sites.

 

Okay, someone who I think is a good guy and gets gets a copy through me or a third party of my table, then gets my hashed passwords. Therefore salt them.

[Pikachu2000]

@ Pikachu2000

 

From what I understand, salting is also method of brute force protection. It has no effect on someone brute forcing a log-in form - this is something your script needs to protect from. It, instead, comes into effect when you actual password hash is compromised.

 

We're on the same page here; that's what I was referring to.

[xyph]

Okay, someone who I think is a good guy and gets gets a copy through me or a third party of my table, then gets my hashed passwords. Therefore salt them.

 

There are other way of dumping the contents of a table - Injection vectors we may not know exist yet.

[ManiacDan]

Okay, someone who I think is a good guy and gets gets a copy through me or a third party of my table, then gets my hashed passwords. Therefore salt them.

 

There are other way of dumping the contents of a table - Injection vectors we may not know exist yet.

Right.  It's possible for bad guys to list your password page through injection attacks, compromised database passwords, exploits in database security, exploits in system security, etc.  Don't think "my friend frank will never steal my database and he's the only one who knows the password."  In the time this discussion has taken place my office network has been attacked tens of thousands of times (I work for a payment processor).

[xyph]

As much as Norton would like you to believe, a port scan isn't really an attack

 

Damn I love being a troll.

[ManiacDan]

Err...did you miss the part where I said I work for a payment processor?  We handle millions of credit card payments a day.  Good trolls usually say things that make sense.

[xyph]

And I'm sure you don't use Norton's line of tools. It was meant in jest.

[RaythMistwalker]

Question on this:

 

Say I wanted to upgrade my current security system by taking the first 3 letters of a users username, and the last 3 letters of their entered password. putting these together then doing md5(Salt.Password.Salt2) (salt2 being a private constant word), then I save the original Salt in a separate database, and then do md5(Username.Salt2) would this massivly boost it compared to me doing this atm:

 

Salt1 (Constant)

Salt2 (Constant)

 

Password = user input

Password changed to: md5(Salt1.Password.Salt2)