Authentication over HTTP

M Stefan <> Sun, 14 July 2013 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7688021F9A83 for <>; Sun, 14 Jul 2013 16:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 53RoG3tWLXbp for <>; Sun, 14 Jul 2013 16:17:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF23A21F9A5B for <>; Sun, 14 Jul 2013 16:17:02 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UyVVz-0000i5-SR for; Sun, 14 Jul 2013 23:15:39 +0000
Resent-Date: Sun, 14 Jul 2013 23:15:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UyVVq-0000fu-Ta for; Sun, 14 Jul 2013 23:15:30 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UyVVp-0005y3-PM for; Sun, 14 Jul 2013 23:15:30 +0000
Received: by with SMTP id o10so7291768eaj.19 for <>; Sun, 14 Jul 2013 16:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aNLNXoZXqsor6m/+i8sJalZC0JZcrg7DMqmbY7+QOMo=; b=RDfT/8x0+ARwaunureZk37Y9s3v4n5X12SdD4lnwl4d9JwiDfk5sadQZce5gAlOduK dMOzrTgCtxZ+Qy2ofJ4O0y/4YBRoVMhmmRRoVKD4OmqdbBEbnSHkDTpLwGU95m+xWVTY PUnkbAI0B4nW8xychT6T5b+EUUt+/A65Hb7xiUjBTv1FSI7Iflc+dX8oZVTUrZDPwhjE Fz4AFmEGdyD1HUNtVqEnTOxKdJEeDBgcwE0ByW0L5LkPEk+p3pi1+2R/A1W8JBT83KuF oMqLc3KCAvmDeWyBavIRqjJFlIE5++kbMuzOx4rbpLRFhY/puk3MWTQgD50OMt/TELzi 01Ew==
X-Received: by with SMTP id 49mr55946290eee.118.1373843703620; Sun, 14 Jul 2013 16:15:03 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id a4sm98120317eez.0.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 16:15:03 -0700 (PDT)
Message-ID: <>
Date: Mon, 15 Jul 2013 02:15:01 +0300
From: M Stefan <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Scan-Sig: 1UyVVp-0005y3-PM 8e08215edb7d23d84955ae8feb554956
Subject: Authentication over HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/18772
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


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

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 

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

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 
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 
Sign up: provides no security against an active man-in-the-middle.
          security against a passive MITM can be achieved through 
schemes such as
Login: if no active MITM was present during sign up, this procedure is 
         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 
         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

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.