Why I'm not enthusiastic about new HTTP authentication methods

| Comments (3) | COMSEC
Yesterday at the IETF SAAG meeting I watched (and then tore into) a presentation about a proposed PAKE authentication mechanism for HTTP. Regardless of the merits of this particular mechanism—and in my opinion they were pretty slight—it's not clear to me that any new HTTP authentication mechanism is going to have a significant impact on the browser authentication problem. [Note: I'm talking here about authentication for users in browsers. The problem is different for non-browser user agents.]

Currently the way that 99+% of Web authentication works is that you connect to the server (hopefully over HTTP) and the server gives you a login page with a password in an HTML form. You type your password into the form and click "submit" and the password gets sent to the server.

Let me start with two premises, that while I think not universally agreed on, are fairly uncontroversial:

  • Passwords aren't going away. Much as we might like everyone to use HTTPS certificate-based client authentication, for the foreseeable future the only credential that people have that's really portable from machine to machine and can be reliably used by servers is passwords.
  • Phishing is the big problem. If people use HTTPS and go to the right site, then passwords work tolerably well (especially if you use a password manager). At least they can be secure. However, passwords aren't very secure at all in the face of phishing.

PAKE systems (or even hash-based systems such as HTTP Digest or PwdHash) are supposed to protect against this threat since the server never gets a cleartext copy of your password. The idea here is that instead of providing a form the server would prompt the client for authentication. The client would then give the user some dialog where they could type in their password (in many cases, the expectation is that they would have a single password which, via the magic of cryptography, they can use with every site; see for instance [HWF05]). The client and the server would perform some cryptographic authentication handshake (without the client giving the server the user's password directly) and at the end of the day the client would be authenticated. In some, but not all, of these systems the client also gets to authenticate the server via the password, but that's mostly a nice to have rather than a hard requirement. The major advantage here is that if you visit the wrong site, the server doesn't learn your password and so can't impersonate you to others.

So, why isn't this that great? The difficult part is the phrase "some dialog where they could type their password". Remember that we're assuming that the user has visited the wrong site and so the attacker controls what they see inside their browser. The natural thing for the attacker to do is therefore to produce it's own dialog that claims to be the dialog for the new authentication mechanism, capture the user's password, and they're good to go. In order to thwart this attack, we need to have the dialog be distinguishable. I.e., it needs to look and/or behave in some way that the attacker can't imitate, even though he controls the web site that the user/victim is visiting. From a technical perspective, there are a number of mechanisms that will work. For instance, anything generated by the site, even if it's a popup, will appear wrapped in "browser chrome" (a frame, most likely, with a title bar) so you could tell the user never to type their password into a dialog box wrapped in chrome. Unfortunately, there is a lot of evidence that users actually don't make this kind of distinction very well (the standard cite here is [SDOF07]). The problem is made even harder by the fact that sites generally want to have a fair amount of control of the look and feel of the login experience, but that makes it even harder to build a UI which is reliably distinguishable.

Going back to the initial question, in my view the major problem here is the user interface/experience. If that problem were somehow solved there are a large number of protocol mechanisms that would significantly improve security. There's some question about what the best set of tradeoffs is between protocol complexity, backward compatibility, etc. but those are just standard protocol engineering issues, not something that's particularly difficult. However, until we solve that user interface problem, I don't see newer, more secure protocol mechanisms adding a lot of value.


"Wrapped in browser chrome"... That's a really bad assumption. It's true for most PC-based desktop browsers. It's almost NEVER true for browsing on any other kind of device. And then on a PC, there are several ways of going full-screen too (flash, HTML5 canvas, WebGL, convince the user to hit ⌘-⇧-F, ...)

Yeah, the interface is the tricky bit. I remember you saying Digest would be ok as a default mechanism at this meeting


and thinking that was really, um, odd. :)

However, I've come to believe that a PAKE mechanism for TLS in browsers would do a lot of good, because most of the use cases for self-signed certs could be addressed with it.

I don't really recall what I said at that meeting, but my position on digest is that while it has many obvious flaws from a protocol perspective, if we somehow got an acceptable UI, then Digest would make phishing a lot harder (since it would require an offline dictionary attack agains the password) and since it has the same upward interface, would pave the way for the deployment of PAKE techniques.

Craig: yes, the UI problem on a mobile device is much more severe. However, the full screen mechanisms you refer to on the browser are designed not to allow you to escape the browser chrome. That's why Flash full screen mode disables keyboard entry, for instance.

Leave a comment