PDA

View Full Version : PHP Security (salt key size)


ast3r3x
2007-11-25, 13:16
I know I've made some other security related questions before because it's an area of interest for me in regards to programming. My question this time is about hashing passwords to protect them from prying eyes. In PHP, there is the hash_hmac function which allows for a salt key. I am wondering if the size of this matters, or if there is a limit.

A long time ago I used to use crypt() because I thought it made me cool because it has crypt in the name, it had to be secure! Then I moved to just md5'ing things and storing them to compare later. Now I'd like to go to the next level using hash_hmac(). My question now I suppose is how do I choose the salt key to use? Originally I'd use the first x characters or whatever of the password. But thinking about this, it is limiting, and if there is no limit to the salt key size, couldn't I just md5 the password and use that as the salt key?

Just curious if you guys have any answers, or what you do to ensure the maximum possible security in your applications.

chucker
2007-11-25, 13:44
Disclaimer: I'm not a security expert.

A Unix timestamp is probably more than good enough as a salt. The point of a salt is to make one and the same password look different when in encrypted form.

Let's say we have a software that doesn't salt its hashes. If both Frank and Lucy use 'hello' as their password, and Joe cracks into the database, he could do a SELECT [..] ORDER BY on the table containing the passwords. If he were to decrypt the hash back to 'hello' (which, using rainbow tables, doesn't take long at all), he'd immediately have both Frank's and Lucy's password, and probably that of dozens of others.

A salt prevents this. Their password would still be the same, but Joe would never know from their hashes, which would look entirely different.

So, really, the salt doesn't have to be secure at all, just different each time. A random() function accomplishes that, but even just a timestamp should be more than enough.

At least I'd say so. Someone please correct me if I'm wrong.

ast3r3x
2007-11-25, 14:12
So, really, the salt doesn't have to be secure at all, just different each time. A random() function accomplishes that, but even just a timestamp should be more than enough.

At least I'd say so. Someone please correct me if I'm wrong.
I understand the purpose, but the salt key has to be the same every time if you want to get the same result, so if you wanted to compare later (like to verify someone's password is correctly entered), you'd have no idea what salt you used right? Am I missing something that would allow you to know what timestamp was originally used?

My logic was that an md5 of the password for the salt is both a 128bit and most likely unique for every person. I just don't know if it's necessary to go that in-depth for a salt. I was thinking that if you had an md5() salt, you'd have the chance of collisions by brute for being say sha512 multiplied by the number of possibilities (or maybe collision likelihood) for the md5 itself.

But maybe there is no point in even running the md5, and just using the password itself as the salt. Either way rainbow lookup tables won't work, but I figured most people don't use 128bit long passwords, so brute forcing would be slightly harder.

chucker
2007-11-25, 14:23
I understand the purpose, but the salt key has to be the same every time if you want to get the same result, so if you wanted to compare later (like to verify someone's password is correctly entered), you'd have no idea what salt you used right? Am I missing something that would allow you to know what timestamp was originally used?

You have to store both the (salted) hash as well as the salt. This is no different whether you use a timestamp, random number or anything else for the salt – you do have to know the salt.

But maybe there is no point in even running the md5, and just using the password itself as the salt.

Heh, no. You can't use the password as the salt – the salt has to be available to you in plain text (or at least quickly decryptable) form.

rollercoaster375
2007-11-25, 14:30
The recommendation I've been given in the past is to hash a user-specific value (ID or username) and then concat it to the password, and hash the concatenation.

As for using the password... While it would work against rainbow tables to hash a doubled password, it doesn't work for pass duplication stuff.

ast3r3x
2007-11-25, 14:58
Heh, no. You can't use the password as the salt – the salt has to be available to you in plain text (or at least quickly decryptable) form.
You shouldn't need to store it if you just calculate the salt based on other things like their password.

The recommendation I've been given in the past is to hash a user-specific value (ID or username) and then concat it to the password, and hash the concatenation.

As for using the password... While it would work against rainbow tables to hash a doubled password, it doesn't work for pass duplication stuff.
Ahh, that makes sense, the username which normally HAS to be unique and the password hashed together. Always a unique hash which stops against rainbow tables AND from anyone person having the same salt. Plus it can only be created if you know the original unhashed password. I like it.

Gargoyle
2007-11-26, 17:48
If you just md5 the username+password you still end up with the same level of security...

You still need to know both and rainbow tables are not going to work because you have concatenated two words together.

ast3r3x
2007-11-26, 18:10
If you just md5 the username+password you still end up with the same level of security...

You still need to know both and rainbow tables are not going to work because you have concatenated two words together.

Right, but isn't it much easier to brute force then since it's only 128bit? Doesn't that mean that collisions are a lot more likely (and I know 'a lot' more is relative here) than something that is 256, or 512 where there are no KNOWN collisions yet?

Plus, and school me if my babbling is based in misunderstanding on any of this please, always looking to get a better handle on it, if they are making rainbow tables of random strings as well as just words, couldn't that be used since they will all be the same? While using something that has a salt key makes any previously generated results useless unless its using that salt key?