Security precautions when submitting log-in information with AJAX.

Question

Hello everyone,

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!

Answer 1

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.

Answer 2

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/

Answer 3

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.

Answer 4

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.

Answer 5

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.)