Re: Authentication over HTTP

On Jul 15, 2013, at 2:15 AM, M Stefan <mstefanro@gmail.com> wrote:

> Hello,

Hi

> As HTTP is fundamentally an old protocol, it has not kept up with
> the more recent developments in cryptography and security. I believe
> that a major change in the protocol version should also take into account
> some security concerns.

Basic and Digest are pretty outdated. There is a working group to deal with this: http://tools.ietf.org/wg/httpauth/

> Nowadays, the only serious way of providing secure communications over
> HTTP is using HTTPS. Many web hosts are reluctant to using it because
> of the extra computational burden and the necessity of buying
> certificates. Some sites cannot afford being part of it or simply
> do not agree with the idea of paying a certificate authority money.

Buying a certificate and turning on TLS is pretty cheap and easy, but only gets the website authenticated to the UA. Getting mutual authentication working requires distributing certificates to users, and that is beyond the means of most websites (exceptions being corporate/government agency VPNs, and sometimes banks, maybe a few others)

> Not every admin cares about security equally, and for those that,
> for one reason or another, choose not to use HTTPS, there should be
> some lighter alternative. It may not have the security guarantees of
> HTTPS but would still be better than current approaches.

Encrypting stuff and then sending it to someone who may be the intended recipient or may be an attacker makes no sense. Good authentication is way more important than encryption. Unfortunately, it's also much harder.

> According to a very popular train of thought, concerns should be separated,
> in that security protocols should be built at a lower layer (and therefore be
> independent) from the HTTP protocol.

Yeah, IPsec is great, TLS is great. But assuming your application supplies different services to different users, the application has to be aware of the user identity. User identity is hard in both IPsec and TLS, so most application opt to do the authentication by themselves. The fact that this pretty much replicates the security properties of HTTP Basic notwithstanding.

> As tempting as it sounds to fragment components into smaller ones as much
> as possible, I believe that a protocol that has the popularity of
> HTTP must address this concerns itself. To find evidence of this fact,
> you don't have to look very far. Simply observe how many websites currently
> send your log in password as plain text. Even IMAP has STARTTLS.

They do that because a form gives the designers more control over the user experience than using any facilities within HTTP. That is something I'm afraid the http-auth working group will not be able to solve, regardless of all the cool crypto that they might add.

> As most websites allow users to sign up and log in, it becomes an
> important question what can be done to have some security when HTTPS
> is not affordable (as is currently the case for most of the web).

I disagree with the affordability claim. But TLS has a lot of ciphersuites, including some that are anonymous. So you can have encryption without authentication even with TLS (for all the good that will do you)

> Websites these days typically receive your password as plain-text upon
> sign up and log in. Upon log in, they provide you with an unique large
> string (the session id cookie) which constitutes proof that you are indeed
> logged in as a certain user. You then have to provide that proof in every
> request you make.

And that session id cookie was the target in the BEAST, CRIME and Lucky-13 attacks.

> This sounds very primitive. The fact that the password is
> sent as plain-text both upon subscription and log in and the fact
> that your proof string (the session id) is reusable are serious flaws
> that I believe to be unacceptable for the most used protocol on the Internet.
> One can argue that this should be the concern of the web developer, but one
> would be wrong. It cannot be expected for every web developer to have the necessary
> knowledge in security to implement a more secure authentication handshake.

Totally agree.

Note also that form-based login can never be more secure than that. I've seen forms that use Javascript to encrypt the password with an RSA key from the server. But those forms are visually indistinguishable from forms that send the password in the clear. So unless we expect the users to read the javascript before entering their password, they will be duped by a look-alike form from an attacker.

> One could also claim that there is no way to have a great deal of security
> without the web host owning a trusted (signed) certificate. While this may
> be true, some security guarantees can still be made even in the absence
> of such a certificate. It makes no sense to believe that "some security" is
> just as bad as "no security".

Disagree. Some security guarantees are not necessarily the security guarantees that matter, and to me it's far more important to know that I'm talking to the correct server than knowing that my traffic is encrypted en route.

> In general, there are three operations that need to be considered for web-sites
> that allow users to authenticate themselves: sign up (rare), log in (often),
> other requests (very often).
> 
> Using HTTPS with a signed certificate, all three operations are secure, and
> relatively fast. In general, public-key cryptography is considered slow,
> whereas computing hash functions and private-key cryptography is considered
> fast.

And thanks to TLS session resumption, public-key cryptography is very rare.

> In the HTTP plain-text setting, all three operations are insecure:
> Sign up: the plain-text password can be intercepted
> Log in: the plain-text password can be intercepted
> Requests: the session id can be intercepted and reused as many times as desired

I've mentioned http-auth (in this message) and websec (just yesterday), so I won't do it again. The hard part is getting the web site owners to use the new technologies.

> The obvious question is: how can most websites, with little overhead, benefit
> from better security (authentication and/or encryption) without too much effort and
> without requiring the web developer to have advanced knowledge about security?

self-signed certificate + DANE + HTTPS ?  Most of this could be automated, but the infrastructure would have to be there (DNSSEC, registrars willing to enter DANE keys in the DNS)

> For instance, an EKE (encrypted key exchange) mechanism could be embedded in HTTP2.0 for
> allowing users to log in. Both the web host and the user share some common secret
> that a third party does not have (a salted digest of the user's password). Using this
> common secret, the host and the user can negotiate a shared key. After this login handshake
> has finished, the server has the guarantee that the client knows the digest of the password.
> The client also has the guarantee that the server knows his password's digest (so
> this provides authentication both ways). On the other hand, a man-in-the-middle
> cannot find the digest of the password from this handshake.

The only reason certificates exist at all is that symmetrical key management is really, really hard. Where do I get my secret key for GMail?

> At this point, the host and the user share a secret key. This key can be used in every request
> for the client to authenticate itself to the server and vice-versa. The shared key becomes the
> "session id" that is commonly used nowadays. Except that instead of sending it directly as a cookie,
> an efficient zero-knowledge interactive proof is mounted. If encryption is desired,
> this shared key can also be used to encrypt communication.
> 
> This mechanism provides the following security for the three operations considered:
> Sign up: provides no security against an active man-in-the-middle.
>         security against a passive MITM can be achieved through schemes such as
>         Diffie-Hellman
> Login: if no active MITM was present during sign up, this procedure is secure
>        this is because the server and the user both know the password of the user,
>        but no attacker knows it. This shared information can be used to perform
>        EKE and exchange a larger shared key.
> Request: Same as for Login. If no active MITM interfered during Sign Up then
>        no attacker can know the shared key. This means that the communication
>        can be encrypted and authenticated with it. Random numbers (nonces)
>        may be used to prevent replay attacks etc.
> 
> Therefore, using this technique, an attacker gets a single chance of attacking an user:
> by taking action upon the user's sign up.
> However, once the password digest has been provided to the server without anyone tampering with it,
> there's little an attacker can do.
> 
> There's a significant difference between exposing yourself once and exposing yourself with every request.
> Registrations are rare. Requests are very often.
> 
> Another technique worth considering is client-side certificates. These can be self-signed and allow
> security during sign up, login and request.
> 
> It is about time we start providing alternatives for password-based authentication on the web.
> I realize I'm dreaming big, but I believe that if HTTP provided client-side authentication
> with certificates, browsers would gladly follow and we could get ourselves a bit further
> away from the evilness behind passwords. Towards a world where we would need to protect
> our private keys with various mechanisms, not remember huge different passwords for every
> site.
> 
> I realize my points are very superficial and are mostly proof-of-concepts. Clearly, MITM
> attacks with active adversary cannot be mitigated at sign up without signed certificates.
> But I cannot stress this enough: once an user has been exposed once, there is no reason
> to expose himself again.
> 
> In my opinion, a major release of HTTP is the right opportunity to address such issues.
> Consider its popularity, as well as the fact that the vast majority of the websites
> that need confidentiality and authentication also offer means of log-in. I believe
> this would be a giant step towards a more secure Web. No modern protocols should
> offer plain-text authentication as their main option any longer.
> 
> I look forward to hearing your thoughts on this matter.
> 
> Stefan

Received on Monday, 15 July 2013 06:52:10 UTC