Is time() a good salt?

Question

I'm looking at some code that I have not written myself. The code tries to hash a password with SHA512 and uses just time() as the salt. Is time() too simple a salt for this or is this code safe?

Thanks for the answers and comments. I will sum it up here for the new readers:

• salt should be different for each user, so if 2 users register at the same time, their salts won't be unique. This is a problem, but not a big one.
• but salt shouldn't be in any way related to the user, so time() is not a good salt.
• "Use a random, evenly distributed, high entropy salt." -- That's a mouthful, so what code could possibly generate a random, evenly distributed, high entropy salt?

Ok, so how about I replace time() with a random string 32 char long. The random string could be generated from looping 32 times over a set of alphabet chars. Does that sound good?

Answer 1

Yes.
It seems that a unix timestamp, stored in the user database as a "Member since" field going to be decent salt.

However, salt question is most negligible one. There are much more important things you have to pay attention to:

1. Most likely not a password nor salt or hashing algorithm going to be weakest part of your site. Some lame file injection or XSS or CSRF surely is. So, don't make a too big deal of it.
   Speaking of a true random string of 32 char long in the typical web-application is like speaking about 32-inch armored door in the wooden barn.

2. Speaking of passwords, most ever important thing is password complexity. With weak password no salt nor hashing algorithm, even super-ingenious-incredible-hard one, could help. It's a pain to ask users to use complex password, but without it everything else becomes a piece of crap.
   So, your first concern should be password complexity. 12-16 characters of different case, including numbers and punctuation is a requirement.

3. As for the salt, I see no benefit in using time, as you have to store it along with other user data. Better use a email - it's random enough and you have it already anyway. Don't forget to rehash a password if user changes their email. it seems that unix timstamp going to be a decent salt, no need to use email or anything else.

Update
As I can see, many people still unable to get the point.
Like that guy from the comments, saying

Many users use weak passwords (we should educate them, or at least keep trying), but that is no excuse; they still deserve good security

They deserve, no doubt. But with weak password the mission. is. impossible.

If your password is weak, then no salt will protect it.

While salt is not that important to spend a 10-kilobyte text on the topic.

Answer 2

Updated

It's not a really good salt, but probably good enough to defeat all but the most determined and resourceful attackers. The requirements for a good salt are:

• Different for each user
• long enough (at the very least alphanumeric 8 characters) to make the concatenation of salt and (potentially weak) password too long for a brute force attack.

time() values are not really long enough, since they have 10 characters, but only digits.

Also, sometimes two users may get the same value when they are created within the same second. But that's only a problem if you have situations where many users are automatically created within the same second.

In any case, far more important than a perfect salt is using a good hash function, and SHA512 is one of the best we have available right now.

Answer 3

the date when a member joins a forum/website is generally openly access able , which would be same as time() hence making your salt useless.