如何在php ajax登录加密/盐期间防止捕获

Question

If a password is encrypted before ajax, what is to stop a hacker from capturing the encrypted password and using it to log in?

Should a unique salt be sent from the backend beforehand?
Wouldn't a hacker be able to capture that too?

I worked through this tutorial
http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL

browser side encrypts password before sending it to backend where it is stored in db

From that link, the first comment stuck in my mind
"what's to prevent a hacker from capturing the hashed password and logging in?"

Answer 1

Nothing. Hashing the password on the client is a terrible idea.

Communication between the browser and server should be properly encrypted using SSL (via HTTPS).

Hashing on the client side has two effects:

• It provides a false sense of security to the site owner by suggesting that it can substitute for SSL
• It adds a dependency on JavaScript

Answer 2

This is a bit silly, really. As Quentin stated, all you've done at this point is change what the password is , you havent made it any more secure. Now, instead of the password being 'private string', it is sha1('private string'). Which happens to be '5ee913d43470d39020f15ac10ff9cf7a8761b55a' if you hex-encode it.

All you've done is trade one password for another.

To exchange passwords securely your best option is to use HTTPS. Hands down. If for some reason you can't get HTTPS working or you don't want to pay for the certificate then you'll have to get creative.

Your hardest problem to overcome is the at the initial stage where the user sets their password. Without using public-key cryptography, your best option is to pass a randomly-generated symmetric key in the form, and use that key to encrypt the password at the client end, and decrypt it at the server end. It can be broken if someone happens to be watching the exchange. But this is a problem that can't be solved without public key crypto.

Once the password is set logins can be done very securely. When the server renders the login form for the client, it can generate a nonce as part of the form:

<input type='hidden' name='nonce' value='b45354f5b437c82beeed71d4d56ef3a47d0df2d3'/>
Username: <input type='text' name='username'/><br/>
Password: <input type='password' name='password'/>

Using a Javascript and a crypto library such as crypt-js , the client creates a hashed message. The message should include a timestamp, the username, and the nonce. Then create an HMAC.

var ts = Math.round((new Date()).getTime() / 1000);
var message = '' + ts + ':' + username + ':' + nonce;
var hash = CryptoJS.HmacSHA1(message, password);

Long story short, the hash is the message hashed together with the password.

Now send the message and the hash to the server. The server has to reverse the process:

• parse the message into the nonce, date, and username
• make sure the nonce was the same one that was given to the client
• make sure the date is recent (within the last 5 minutes, say)
• retrieve the user's password
• perform the HMAC computation, and make sure the outcome equals the hash provided by the client.

Answer 3

The tutorial you posted does not only hash on the client side... they hash on the server side as well.

Basically on that registration page, something JavaScript will hash the user's password and send it to the server. Presumably, this is to stop someone from getting the password in transit. Once the hashed password is sent to the server side, it is salted and hashed again.

This method is safe... but I'm not sure I see the merits of hashing on the client if you are using HTTPS, which you should be.