sh1 and salt

NZ_Kiwis

So I'm looking at inserting passwords into my database, I'll be using sh1 as my encryption and i'll be using "salt"

From what I gather, salt is my users password appended with my special code "Ds#g^'}" for example, these combined are the encypted and stored in my database?

Is this correct?

If so when a user logs in, do I get compare their $_POST['passowrd'] . ""Ds#g^'}"; with what's in my database?

Am I on the right track?

If not can someone help me?

dalecosp

That's basically the right track. Salt is just some extra randomness that helps guard against certain types of attacks.

From a popular, unnamed, PHP software package:

$password = md5(md5($pass.$salt));

Salt is generated for each user and stored in its own DB field. The hashed pass is also stored. For verification, look up the users' salt and run the same routine on the submitted password with the salt. If they match, it's valid.

I will add that the salt is much longer than the 4-5 characters you've used in your example ... but I'm pretty sure you knew that already ;-)

traq

dalecosp;11029819 wrote:
Salt is generated for each user ...

That might bear repeating: salts are user-specific: you don't use the same one for everyone (or even just two people). This would defeat the basic purpose of salts - if two users had the same password and same salt, their hashes would be the same (tipping an attacker off to a good place to start hacking). If the salts are different, the hashes will be different, even if every user's password was identical.

bradgrafelman

dalecosp;11029819 wrote:
$password = md5(md5($pass.$salt));

...except that example also shows two things not to do: 1) chain hash results together with an algorithm that doesn't preserve the original entropy, and 2) use MD5.

dalecosp

Good point, Brad; I'm not looking at source code for the unnamed project since it's the weekend. I'm pretty sure that they did chain it, though. I'm not certain of what algorithm was in use either, but it may well have been MD5....

NZ_Kiwis

So two things

Could do md5 my salt, sha1 my password and sha1 the combined result?
What column name would you call your salt? Salt seems to obvious for a hacker or do you store it in a different database and or table?

Weedpacket

Or use an existing salting mechanism (native from PHP 5.5, though implementations for earlier versions exist). Note that the salt can be derived from the hash and hence doesn't need to be stored separately.

NZ_Kiwis

Weedpacket;11029829 wrote:
Or use an existing salting mechanism (native from PHP 5.5, though implementations for earlier versions exist). Note that the salt can be derived from the hash and hence doesn't need to be stored separately.

Is this an answer to my question?

traq

Weedpacket;11029829 wrote:
Or use an existing salting mechanism (native from PHP 5.5, though implementations for earlier versions exist).

f*n cool.

I wasn't aware of this. Thanks very much for pointing it out.

Bonesnap

I wouldn't use MD5 or SHA1. Instead I would use nothing less than SHA256 (SHA512 is my preference). Your salt should be just as long as your password hash (again I use SHA512), and should be very random (a simple mt_rand(getrandmax()) is not good enough). Once you have your salt, you can do what you want with it and your password. Most applications append the salt to the beginning or the end of the password and then hash that. I personally like to do something a little different and split the salt in half and place one half at the beginning and one at the end.

I have started using what's known as a pepper, which is something that's stored in your source code that's used when hashing the password. Unlike the salt, it is a constant value (I also use SHA512 for this). This adds an additional layer of security to your application because now you're basically forcing an attacker to get both the database and your source code to crack the passwords (usually just the database is compromised).

NZ_Kiwis

so if each user has a their own "salt" where do I keep that so i can reuse that when i compare the password when they login? storing it in the users table seems pointless

traq

NZ_Kiwis;11029929 wrote:
so if each user has a their own "salt" where do I keep that so i can reuse that when i compare the password when they login?

if you use [man]crypt[/man] (or the password_* functions Weedpacket suggested), the salt is prepended to the hash. Store it all together.

NZ_Kiwis;11029929 wrote:
storing it in the users table seems pointless

why?

laserlight

Bonesnap wrote:
I wouldn't use MD5 or SHA1. Instead I would use nothing less than SHA256 (SHA512 is my preference).

In the long (but probably not too long) run, SHA256 and SHA512 are not much better than MD5 or SHA1 for this purpose. I believe that even MD5 is still resistant to preimage attacks, hence MD5 for this purpose is theoretically as good as SHA512 right now, as long as your users choose sufficiently good passwords (but we know they won't).

Better options for this would be methods specifically designed for this purpose, e.g., PBKDF2, bcrypt or scrypt.

Bonesnap wrote:
Your salt should be just as long as your password hash (again I use SHA512), and should be very random (a simple mt_rand(getrandmax()) is not good enough).

I think that that is a misconception: increasing the length of the salt by hashing it does not add to security since it does not change the entropy and the attacker is assumed to know the salt anyway; he/she does not need to know the input of the hash function. The salt should be unique, not just unique on your system but everywhere, hence the purpose of using a random value rather than say, the auto-incrementing integer primary key of the users table. Hence, I would argue that mt_rand(getrandmax()) is "good enough", though there is negligible cost to go beyond this "good enough" and hence you should.

NZ_Kiwis wrote:
so if each user has a their own "salt" where do I keep that so i can reuse that when i compare the password when they login?

As dalecosp mentioned, one option is to store it in its own field in the database. As Weedpacket noted, the salt, or a hash from which the salt is derived, can be stored along with the hashed password, e.g., some common schemes use a '$' to separate the salt from the hashed password, then store them together in the same database field.

NZ_Kiwis wrote:
storing it in the users table seems pointless

No, it would be sensible: the salt is part of the information required for authentication, hence storing it in the users table along with the username and hashed password is a good idea. Perhaps you say it is pointless because it would defeat the security that you are after, but the ideal properties of any appropriate hash function used (or password hashing scheme thereof) is such that the salt value can be revealed to an attacker without compromising security.

NZ_Kiwis

So a users table would have columns username, password & salt. When logging in, I would find the username which matches the $POST['username'] get the $row['salt'] add that to the $POST['password'] cypt with md5, sha1, sha512 or a combination of them and compare it to $row['salt'] . $row['password'] which are my stored encrypted data.

laserlight

No, you would compare the final result to just $row['password'].

NZ_Kiwis

So my stored password will include the "salt"?

laserlight

NZ_Kiwis wrote:
So my stored password will include the "salt"?

Hmm... I don't think you understand the concept at all.

Suppose that you have a cryptographic hash function H. You compute:
hashed_password = H(plaintext_password + salt)
then store hashed_password and salt in the database (in the same field or otherwise, whatever), associated with the username.

To login, the user provides username and supplied_plaintext_password. You need to compute:
result = H(supplied_plaintext_password + salt)
and then check that result == hashed_password. Obviously, you can only obtain salt and hashed_password by using the supplied username to find the row.

In practice, H may be more complex than just a cryptographic hash function primitive, e.g., if you explore the link in Weedpacket's post #7, you will see that bcrypt is currently offered as an algorithm.

NZ_Kiwis

yeah i think i get it now, so salt is just stored in the same user table and same user row - was thinking if a hacker got my users table wouldn't it mean they could hack my salt then make hacking my password easier?

Weedpacket

No, because there's no point in "hacking your salt" - it's random, there's no information in it. They still need to hack the password and the salt means they have less information to work with. As laserlight said, it's assumed that the attacker knows the salt (and the hash algorithm).

They could take their dictionaries and rainbow tables and construct versions in which [font=monospace]masterpa55w0rd[/font] (if the user has picked such a weak password as that in the first place) has been replaced by [font=monospace]CJpTh0Qyj5ACTlV0wUz6Zp/K1ah9FwJGpAxBwO7nY1VpBli2AJXHSHW7H7UjDgkb8blkMRErlwqDOZs8masterpa55w0rd[/font] and then try to brute-force the password of the user with the salt [font=monospace]CJpTh0Qyj5ACTlV0wUz6Zp/K1ah9FwJGpAxBwO7nY1VpBli2AJXHSHW7H7UjDgkb8blkMRErlwqDOZs8[/font]. If they succeed, they will have one password, and the effort would be no help whatsoever at getting any of the others.

I'm waiting for keccak to be available as a hash algorithm.

Bonesnap

laserlight;11029949 wrote:
In the long (but probably not too long) run, SHA256 and SHA512 are not much better than MD5 or SHA1 for this purpose. I believe that even MD5 is still resistant to preimage attacks, hence MD5 for this purpose is theoretically as good as SHA512 right now, as long as your users choose sufficiently good passwords (but we know they won't).

Better options for this would be methods specifically designed for this purpose, e.g., PBKDF2, bcrypt or scrypt.

Yeah something like bcrypt probably is ultimately the best choice.

laserlight;11029949 wrote:
I think that that is a misconception: increasing the length of the salt by hashing it does not add to security since it does not change the entropy and the attacker is assumed to know the salt anyway; he/she does not need to know the input of the hash function. The salt should be unique, not just unique on your system but everywhere, hence the purpose of using a random value rather than say, the auto-incrementing integer primary key of the users table. Hence, I would argue that mt_rand(getrandmax()) is "good enough", though there is negligible cost to go beyond this "good enough" and hence you should.

The reason to make the salt ridiculously long is for the cases where the attacker doesn't have access to it (if your database is compromised you have no idea how the information will be used), and is simply trying to brute force it. You can probably get away with something less, but like you said, there's really no cost to going beyond.