Send password safely using an ajax request

just to know, is it possible to send password through an Ajax request safely?

I've a login box that cal开发者_开发问答ls an ajax request to try the login/pass and retrieve a JSON Object with errors (if any).

Should I use a form redirection instead?

[EDIT] Store the encrypted password in the database isn't the solution because the login and password send by ajax are the login / password to access the database itself (internal application).

---

The only way to send something that can not be intercepted by a third party is by using HTTPS instead of regular HTTP. That way everything sent between the server and the client is strongly encrypted.

---

For the technical hell of it, you can. If you have access to a one-way cryptographic function crypt(text,key) that supports crypt(crypt(T,A),B) == crypt(crypt(T,B),A) you can do the following:

• Have a secret key for your application, KEY. Never tell anyone.
• When the user registers, store crypt(password,KEY) in the database.
• When the user wants to log in, send them a randomly generated key RAND
• The user types the password, the form computes and sends crypt(password,RAND) through unsecure AJAX. The password never leaves the user's computer.
• The server computes crypt(crypt(password,RAND),KEY) from the form response, crypt(crypt(password,KEY),RAND) from the database, and compares the two. They should be equal.

All of this is unnecessary complicated an requires a lot of effort to implement correctly and securely. Buying an SSL certificate and using HTTPS is orders of magnitude easier to achieve this level of security, and even more.

---

Here's what you could do:

Hash Password and store in database

On client side: hash password, then add salt (concatenate session_id string), then hash again

On server: take hashed pw from database, then add salt (concatenate session_id string), then hash again

[Edit: and then compare the hash-salt-hash generated on the server with the one sent from the client]

Intercepting your hash-salt-hash password is quite useless now, because it is only valid for that particular session...

---

What you're looking for is a "zero knowledge protocol". It is a way of communicating that you know a password without sending it. You would communicate between the javascript running in the user's browser, and the server.

Bonus, these protocols are generally secure even if the connection isn't encrypted. Note that it would be stupid to rely on this and not use SSL, because a man in the middle would simply replace your nice zero knowledge protocol implementation with a look-alike function that just sends the password.