Authentication over HTTP

[M Stefan <[e-mail]>]

Hello,

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.

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.

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.

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

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

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.

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.

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

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.

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

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?

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.

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