To authorize user I'm sending salted hash over the air. My question it is more secure to obtain randomly generated salt (but send unencrypted), or have one salt on client (desktop application) and server?


2 Answers 2


For security, neither is secure. Sending a hash from the client to the authentication server does nothing to protect against password sniffing because the hash is acting as the password. The only thing sending a hash does is to mitigate against password reuse attacks (eg. Preventing an attacker from using the same password on site A for site B).

Also keep in mind that salting a password mitigates against rainbow table attacks and nothing more. Salt is not considered private information, so encrypting the salt is a useless operation doing nothing to increase the security of the authentication process.

Without using encryption, or having a dedicated line, you cannot send authentication tokens in the clear and maintain security. Turn on SSL to create an infinitely more secure environment.


This is not a good approach to authenticate the user. If you want to use passwords to authenticate the user, you should first establish a secure connection between the client and the server, using SSL or TLS. (Make sure the client is checking the server's identity, using the server's cert.) For instance, you might use HTTPS. Then, transmit the password from the client to the server over this secure channel. The server can then check whether the password is valid.

To store the password, the server should use bcrypt, scrypt, or PBKDF2 to hash the password before storing it. Include a random salt. Choose the number of iterations to make the password hashing operation take some fixed amount of time: say, 10ms, or 100ms. This ensures that trial-and-error password search will take longer.

When the user initially selects their password, you might consider including a password strength meter, to encourage them to choose a strong password. You might also provide a little widget that automatically pre-generates a strong random password for them and suggest they use it. Include a button (maybe labelled "Use it!") to copy it to the password field, to make it easy for the user to adopt the suggested password you generated for them.

Also, you might consider including some rate-limiting to make it harder to find people's passwords by testing them. See here and here and here for discussion of this topic.

  • 2
    All good recommendations, but better yet - don't use passwords at all, consider something like OpenId or OAuth.
    – AviD
    Mar 16, 2012 at 12:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .