Security precautions when submitting log-in information with AJAX

I am in the process of writing a login/register form for my MVC website and am facing an issue regarding security and AJAX. It seems that more and more popular sites are utilizing javascript to process logins, and many from a non https URL (www.giantbomb.com and www.gametrailers.com to name two). I'm 开发者_开发百科wondering if there is a way for me to do something similar, but also utilize SSL.

I've read in other posts that this is possible if the javascript was executed from a secured page, but if that isn't an option, then how would I go about make the transaction as secure as possible?

Thanks for your time!

---

I guess I just needed a little bit of motivation, or something. Here's some reading you should find useful:

http://shop-js.sourceforge.net/crypto2.htm

http://www.hanewin.net/encrypt/

---

I'm afraid but I don't really have a positive answer for you. Do NOT rely upon JS at all for security. It is trivial for an attacker to replace your "security JS" with a malicious one if you are sending your "security JS" over plain-text HTTP. A malicious JS can post user credentials to the attacker, then inject your "security JS" back to the user browser. The end user and your web service/app will never even come to know someone has captured the user credentials. By "security JS" I mean any implementation of JS - whether asymmetric or symmetric.

---

As George Marian mentions, you could use JS-based public key encryption. There are several implementations available. But you need to be aware that this is not a replacement for SSL. The main difficulty is to distribute the public key in a secure manner. You can improve security with regard to passive eavesdropping, but unless you can transmit the key securely, active MITM (man-in-the-middle) attacks are still possible.

Also keep in mind that JavaScript must be enabled for it to work, so you'd need a plaintext fallback.

If you need to keep things truly secure, use SSL.

---

This question has been addressed on StackOverflow previously. Have a look here for one example.

The big issue with the non-SSL approach is the man in the middle attack. No way to get around it.

---

I would recommend against this because it even if you make it secure, it will look to the user like it isn't. Users are trained to look for the padlock in the web browser, and if it's not there, don't trust it.

(I'm sure someone will point out I'm over estimating the education of users, and yes, not all users know this but many do.)