Neil Kandalgaonkar wrote:

I added a comment to the talk page.

http://www.mediawiki.org/wiki/User_talk:Akshay.agarwal

Long story short, we had this discussion in IRC... some people find the concept of AJAX login really alarming from a security perspective, but I think there could (COULD) be some ways to compromise there. There is a little-used concept called Digest Authentication that we could implement in Javascript.

Using AJAX is not more insecure than normal login using POST (which should be kept for non-js clients). You just need a begin request before the one that transmits the credentials.

I don't find the concept alarming. The concept of AJAX login is perfectly fine, when used on a full https site, or a full http site.

It is insecure when used on an http page where the login page is using https. If there is a man in the middle, the form can be rewritten to send the username/password to the attacker, who then relays the information to the wiki. I don't see how digest authentication will solve this. Digest authentication protects against replay attacks, but I don't believe it can protect against man in the middle attacks.

I should follow this up with: as discussed on the channel, I love the idea of someone working on AJAX login support. It is perfectly useable by a bunch of third parties, and would be a great addition to the software.

Respectfully,

Ryan Lane

On 3/25/11 3:20 PM, Aryeh Gregor wrote:

On Fri, Mar 25, 2011 at 3:19 PM, Neil Kandalgaonkarneilk@wikimedia.org wrote:

...

Long story short, we had this discussion in IRC... some people find the concept of AJAX login really alarming from a security perspective, but I think there could (COULD) be some ways to compromise there. There is a little-used concept called Digest Authentication that we could implement in Javascript.

What are the security problems with a simple AJAX login implementation that just POSTs, compared to digest authentication?

With digest authentication you can transmit credentials over unencrypted HTTP without worrying that someone is capturing your plaintext password, say in a log file, and can log in as you later.

Ryan is correct that a man in the middle who captured digested credentials could log in as you that one time. But not a subsequent time. So they'd have to do their damage right away. But, if you also bind the session to a particular IP, the attacker has a harder time exploiting this without being detected.

I don't have a complete solution thought out, I was just musing that maybe this kind of thing could be useful if we wanted a solution that worked over plain HTTP. But Ryan is also worried about a MITM that corrupts the surrounding page, so that the HTTP-served software that tries to make this HTTPS connection is already compromised.