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()

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

No, time() is not a good salt

It's best not to reinvent the wheel when it comes to authentication, but to answer your question, no. The problem with time():

• It's predictable and it correlates to potentially discoverable things. These issues make it easier to cross-match different hashed results.
• There aren't very many possible values. Since the high-order bits don't change, it's an even narrower salt than it first appears.
• Using it repeats previous mistakes. If this app were the first one to use time() as a salt, at least it would require a new attack.

Answer 3

This post may veer a little too far away from your original question, but I hope you find it useful;

Security is about raising barriers and hurdles; defence in depth. There is no truly secure hashing solution, just ones that are hard to break. It's like putting in a burglar alarm and window locks in your house - make your site less attractive to break into than someone else's.

Salt for a crypt algorithm is only a small part of the security problem. A single salt simply means that there is one less thing to figure out when trying to break the password for multiple users. A low-entropy salt (such as the server's time) makes it a little bit harder, and a high-entropy salt makes it harder still. Which of these to use, and whether it's something you need to worry about primarily depends upon both the sensitivity of the data you're protecting, but also what other security measures you have in place. A site that just gives a personalised weather forecast for a selected city obviously has less sensitive data than one which has your home address, mother's maiden name, date of birth and other info which could be used for identification purposes.

So here's the rub; a high entropy salt is still a bad salt if it's easily obtainable.

In the real world, storing a salt in the database (random or not) is probably less secure than using a constant salt and burying it away from private eyes in a file inaccessible via the web browser. Whilst a unique and high entropy salt is harder to guess, if you've allowed root login from any server on MySql and set the password to 'password' it doesn't really matter! Constrast how easy it is to crack the database versus getting a valid login to your server - which is possibly more difficult to do discretely as you can put fail2ban and a plethora of other attack vector watchers in place depending upon your setup.

You can combine the two approaches by storing the location of a file containing a user-specific salt in the database, rather than the salt itself. Whether having to crack both the file system and the database is warranted depends whether the sensitivity of the data you are trying to protect warrants this overhead.

Another, alternative, recommendation from security experts is to store the username in a separate database (and ideally different technology) to the password, and reference between the two using a UUID. E.g. use both MySQL and SQLite. This means that both databases have to be cracked (and is also why, to go down a separate rabbit hole for the sake of an example, you should not store user details and credit card numbers in the same database since one is of no use without the other).

Note that Algorithms like SHA-512 and Blowfish can return the salt as part of their hash. Be careful with these as if you store the complete hash you give away the algorithm, which means there's two less thing for the hackers to figure out (the salt also gives away the algorithm).

Make sure you enforce strong passwords and usernames, so dictionary attacks will fail; I know of dictionaries for all 6-alphanumeric combinations of username/ password entries for MD5 and I suspect that there are more than this available for all sorts of algorithms. With the explosion of low-cost cloud and CPGPU computing, the size and complexity of available dictionaries is going to explode.

Ultimately, the most secure way is never to programatically generate a salt but require a user to enter it along with their username and password over a SSL link (so can't be snooped), but never store it. This is the approach taken by credit card companies; i.e. the 3-digit CSV security key on your credit card which you have to enter each and every time you buy online, since it should never be stored in any database. If you really want to generate the salt, send it to them separately (e.g. via SMS message or Email) and still make them enter it manually each time. With this approach, although more secure, you need to contrast the complexity against whether users will just stop using the site as you've made it too difficult for them to be bothered with it.

All of the above still relies on the fact that you also have protection in place against session hijacking, cross-site scripting, etc., etc. The world's strongest password algorithm is irrelevant if all I need to do is to calculate a valid PHPSESSID for a logged-in user and hijack it!

I am not a security expert, but have read up on this as much as I reasonably can do. The fact that there are so many books on the subject indicates how big the answer to your question really is.

A couple of really great books you might like to try which I've found invaluable are;

Web Application Vulnerabilities Detect, Exploit, Prevent - ISBN-13: 978-1-59749-209-6

Preventing Web Attacks with Apache - ISBN-13: 978-0-321-32128-2

Answer 4

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.

Answer 5

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 6

The user name should be sufficient enough and perhaps the registration time stamp, but you should store it somewhere in the database. Anyway every value you use to salt your password hash, should be stored some way, so you can recalculate the hash.

Is salting with user name + a time stamp secure enough? It should be. For cracking SHA512 Hashes normally Rainbow Tables are used. A user name + a time stamp should be a salt which is uniquq enough, so there is no way there is some Rainbow Table on the net which contains precalculated hashes with passwords, which are salted this way.