Salt...before or after hash?

[Jessica]

I have been reading up on salting for password storage. Most of the articles I've read said to add the salt to the password and then hash it.

Before I had read too much, this is how I was planning on doing mine. Can anyone offer advice as to if this will work as well or not as the regular method?

 

I was planning on adding random characters to the hashed password.

So it would be like:

$pass = md5($pass);
$salt = rand(0,9).rand(0,strlen($pass)).' '.rand(0,9).rand(0,strlen($pass)).' '.rand(0,9).rand(0,strlen($pass)).' '.rand(0,9)rand(0,strlen($pass)).;

Now, each of the random number pairs will stand for how many random characters have been entered, and where in the string they were injected.

 

I just thought this might be a bit harder to decode than the original method. Am I off my rocker?

[Azu]

It won't be possible to use the MD5 when there are random numbers/letter injected into it.

So you'll have to put them in in a way that they can be easily removed.

Hackers will just do this also.

 

The rand strlens might actually let them decode the MD5 faster since it lets them know some of the characters that are in the password.

[Jessica]

I don't think you understood what I was saying, it wouldn't let them know characters in the password...

I would actually think it would make it harder to tell that it is md5.

 

Say the password is 'apple'.

The md5 would be 1f3870be274f6c49b3e31a0c6728957f

 

Then the salt was

520 310 21 45

 

It would insert random (and not stored anywhere) strings of characters that were 5 long at spot 20, 3 long at spot 10, 2 at spot 1 and 4 at spot 5.

 

So the end would be for example:

1(f9)f387(ef3a)0be27(bc7)4f6c49b3e3(b4b7e)1a0c6728957f

Which is stored as:

1f9f387ef3a0be27bc74f6c49b3e3b4b7e1a0c6728957f

 

 

[hostfreak]

I don't see anything wrong with it, it seems like it would make it harder. I don't exactly understand how you plan on checking against the password though (for login or what have you)... unless you plan to store the random characters and there position too? Then re-add them upon authentication.

[Jessica]

No, I store how many characters and where they are. That is how I know how many and where to remove. Thus, the salt fo the above is 520 310 21 45.

[Gath]

Just a little curious about how it works, but, if some hacker got the hands on the passwords on the DB, wouldnt he also had the possibility to take the code from the php pages?

Altought a little more security cant hurt... he might not take hte time to check the code.

[hostfreak]

Ah, ic how your doing it. Seems pretty ingenious.

[448191]

You say 'not stored anywhere', but how are you going to reproduce the final hash then?

[Jessica]

You don't, you remove the random stuff from the hash which is stored in the database, and compare that to the hashed password they entered.

 

So I have three fields: username, salt, password. (Well obviously I have more but these are what matter right now.)

The user enters their username: wormy

Their password is apple, so they enter apple.

The SQL then gets the stored hashed and salted password for user "wormy" which is 1f9f387ef3a0be27bc74f6c49b3e3b4b7e1a0c6728957f

and the salt which is 520 310 21 45.

The code then removes all of the random characters which were entered to get the MD5 hash which is: 1f3870be274f6c49b3e31a0c6728957f

The code then runs md5 on the user entered password: apple.

1f3870be274f6c49b3e31a0c6728957f

1f3870be274f6c49b3e31a0c6728957f

 

And they match, so it's the user!

 

Maybe doing a combination of this and the regular salt method would work best for me.

Of course, I think there would be ways to do a salt without having to store anything extra.

 

say your salt was added before the password is hashed.

Our user Wormy wants to use the password "apple". So before it is hashed we add other account information which is stored, such as their userID, their email, username or username length, etc. This is information we need to store anyway, and someone who has our database will not see a "salt" field and know that the passwords are salted, without seeing the code.

The user still needs to know their password to login, but we simply add on the info before hashing it and comparing it to the DB.

 

Just some other ideas.

 

 

Gath - not if your database server is not the same as your file server. There are plenty of ways people could gain access to the DB and not have the code. They could also have only some access such as SELECT but not UPDATE or INSERT, and would need to decrypt a password. *shrug*

 

I just wanted to explore using salt, and this was the idea I came up. There is no perfect solution to security but we can still add little tricks, right?

[448191]

The SQL then gets the stored hashed and salted password for user "wormy" which is ........ and the salt which is 520 310 21 45.

 

You don't reproduce the final hash but instead reproduce the md5 hash taking out the salt. Same thing in essence. You said you weren't storing the salt.

 

Anyway, I guess it's a little safer than just hashes as long as an attacker isn't aware that you are salting hashes. You might want to insert  a salt and then hash it, just to be sure you produce a valid hash. Also, consider sha256 instead of md5.

[Jessica]

The actual characters which are inserted, I'm not storing them in the salt field is what I said. Those characters are not stored, as opposed to a salt which has to be stored. I'm storing numbers which don't mean anything to someone looking at the database.

[dbo]

This works though it's kinda weird and overkill. There is really no need to salt at all except to avoid dictionary attacks. So just using a salt is pretty safe, but like I said it works and if you want to do it this way go for it

 

Personally, I'd use a salt method and then if security is a huge concern I'd implement functionality that locks an account after x failed attempts for x minutes, or force a password change.

[deadimp]

I think dbo's right in that the random salt is kinda overkill. If you want more security for your hash, use another method not as common, such as sha1 using the hash() function. There's a post on GDNet that talks some about this kind of security.

[Azu]

I don't think you understood what I was saying, it wouldn't let them know characters in the password...

I would actually think it would make it harder to tell that it is md5.

 

Say the password is 'apple'.

The md5 would be 1f3870be274f6c49b3e31a0c6728957f

 

Then the salt was

520 310 21 45

 

It would insert random (and not stored anywhere) strings of characters that were 5 long at spot 20, 3 long at spot 10, 2 at spot 1 and 4 at spot 5.

 

So the end would be for example:

1(f9)f387(ef3a)0be27(bc7)4f6c49b3e3(b4b7e)1a0c6728957f

Which is stored as:

1f9f387ef3a0be27bc74f6c49b3e3b4b7e1a0c6728957f

 

 

Oops sorry. When I saw the random strlens I thought you were randomly picking characters out of the password lol.

[Jenk]

You appear to be mistaken for the purpose of a salt.

 

This would be a salted password:

$pass = 'apple';
$salt = 'abc123';
$md5 = md5($salt . $pass . $salt);

 

The salt would never be revealed to anyone, and is kept constant. This is so that:

 

$pass = $_POST['password'];
$salt = 'abc123';
$query = "SELECT * FROM `users` WHERE `password` = '" . md5($salt . $pass . $salt) . "'";

 

I do like your idea, but it would be either difficult for you to manage, or easy for someone else to crack. Especially when they realise it is of non-compliant length to any known algorithms.

[rarebit]

I know it in a similar form to Jenk, where you just concatenate a constant salt string to the password and then hash it. This prevents a standard hash lookup table being used, yet one can be created once the salt is known.

 

If your product is open source then you'll want to make this a variable so it can be set on a per installation basis. Also if changed then all users should be forced to update password, and would require the use of an old_salt variable and a check against either variation. However if they haven't updated within say a month, then stop using old_spice and force them to request a new password...

[MmmVomit]

I see potential problems using random numbers like that.  What if you generate numbers like this?

 

912 413 ...

 

You're inserting nine characters at position 12, then four characters at position 13.  If you're not careful about how you insert and remove the salt from the hashed password, it could cause real problems.

[MmmVomit]

You appear to be mistaken for the purpose of a salt.

 

This would be a salted password:

$pass = 'apple';
$salt = 'abc123';
$md5 = md5($salt . $pass . $salt);

 

The salt would never be revealed to anyone, and is kept constant. This is so that:

 

$pass = $_POST['password'];
$salt = 'abc123';
$query = "SELECT * FROM `users` WHERE `password` = '" . md5($salt . $pass . $salt) . "'";

 

I do like your idea, but it would be either difficult for you to manage, or easy for someone else to crack. Especially when they realise it is of non-compliant length to any known algorithms.

Something interesting that was brought to my attention recently.  If you're using a constant salt, any two users with the same password will have the same password hash stored in the database.  This means if anyone were to get access to your database, they could see if any users have the same password as an account with a known password.  It's a small security concern, but valid.

 

A solution to this was to assign a randomly generated salt to each user.  This could be stored in a field in the user table in the clear.  If someone were to gain access to the user table, they would have no way of matching up accounts with the same password, unless they were to know your particular salting scheme.

[Jenk]

You appear to be mistaken for the purpose of a salt.

 

This would be a salted password:

$pass = 'apple';
$salt = 'abc123';
$md5 = md5($salt . $pass . $salt);

 

The salt would never be revealed to anyone, and is kept constant. This is so that:

 

$pass = $_POST['password'];
$salt = 'abc123';
$query = "SELECT * FROM `users` WHERE `password` = '" . md5($salt . $pass . $salt) . "'";

 

I do like your idea, but it would be either difficult for you to manage, or easy for someone else to crack. Especially when they realise it is of non-compliant length to any known algorithms.

Something interesting that was brought to my attention recently.  If you're using a constant salt, any two users with the same password will have the same password hash stored in the database.  This means if anyone were to get access to your database, they could see if any users have the same password as an account with a known password.  It's a small security concern, but valid.

 

A solution to this was to assign a randomly generated salt to each user.  This could be stored in a field in the user table in the clear.  If someone were to gain access to the user table, they would have no way of matching up accounts with the same password, unless they were to know your particular salting scheme.

Quite, which is the very reasons salt's were introduced.

[MmmVomit]

But this is a weakness even if you are salting passwords.  Without salt, if someone gains access to your database all they have to do is check a dictionary of hashes to find the password. 

 

password = "foo"

md5(password) => acbd18db4cc2f85cedef654fccc4a4d8

 

All someone has to do is find "acbd18db4cc2f85cedef654fccc4a4d8" in a dictionary and look up what it was hashed from.  With salt, they can no longer check a dictionary of passwords because they don't know what the salt is. 

 

password = "foo"

md5(password . "salt") => 26349fe6f276af7590bb7e3448479153

 

Now an attacker can nolonger simply look up the hash and find the password, because they don't know what the salt is.  However, if the salt is the same for every user, they can still see if two people have the same password.  Anyone who has "foo" for a password will have the same hash stored in the database.  If they see that someone has the same hash as the administrator, they know that the admin and the other user have the same password.  If they can trick the other user into giving up their password, they can gain access to the admin account.  If each user is assigned a unique salt, this attack isn't feasable.