Is it better to salt the string when creating a secure hash?

Question

I'm not really strong at cryptography, so there is my question.

Our application — forum — sends our users notifications of new messages, if they opted for it. In the email there should be a link to unsubscribe from this messages. Now, I want that link to work, even if the user is not currently authenticated at our service (no cookie).

To do that, I decided to just sign the request with SHA1, like this:

http://example.com/unsubscribe?u=234&s=52342&h=0b071440146545eaf3f00ef9cdeb1d47d006dfff

Here u is the ID of the user, who wants to unsubscribe, s is some random salt, h is the secure hash calculated by concatenating the name of the action (unsubscribe), parameters and their values (u=234s=52342) and some secret string, specified in the configuration of our service and calculating SHA1 hash of the resulting string:

sha1('unsubscribeu=234s=52342supersecret')

My question is about this parameter s, which is generated randomly every time. Does it add to the security here or not? Is it really needed?

If I go with the encryption instead, does it make sense to add this kind of salt to the data being encrypted?

This is more of a theoretical question, since it is very unlikely that someone would want to guess that "supersecret" at our service just to prank-unsubscribe a bunch of users, but still interesting.

Answer 1

The main use for a salt is to prevent comparison of various hashed values for analysis; for example, to see if any two users have the same passwords by comparing the hash values of their passwords. If random salts are added, that comparison is not possible (unless both the passwords and the salts are equal - which should not happen because a salt should be random)

In your case, I don't think there is any benefit from the salt value unless you also store those salts on the server end and 'expire' them once used, so that a certain unsubscribe link - with its salt value - could not be 'replayed' again later.