Authentication over HTTP
M Stefan <mstefanro@gmail.com> Sun, 14 July 2013 23:17 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7688021F9A83 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 14 Jul 2013 16:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53RoG3tWLXbp for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 14 Jul 2013 16:17:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AF23A21F9A5B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 14 Jul 2013 16:17:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UyVVz-0000i5-SR for ietf-http-wg-dist@listhub.w3.org; Sun, 14 Jul 2013 23:15:39 +0000
Resent-Date: Sun, 14 Jul 2013 23:15:39 +0000
Resent-Message-Id: <E1UyVVz-0000i5-SR@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mstefanro@gmail.com>) id 1UyVVq-0000fu-Ta for ietf-http-wg@listhub.w3.org; Sun, 14 Jul 2013 23:15:30 +0000
Received: from mail-ea0-f174.google.com ([209.85.215.174]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <mstefanro@gmail.com>) id 1UyVVp-0005y3-PM for ietf-http-wg@w3.org; Sun, 14 Jul 2013 23:15:30 +0000
Received: by mail-ea0-f174.google.com with SMTP id o10so7291768eaj.19 for <ietf-http-wg@w3.org>; Sun, 14 Jul 2013 16:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.14.2.73 with SMTP id 49mr55946290eee.118.1373843703620; Sun, 14 Jul 2013 16:15:03 -0700 (PDT)
Received: from [192.168.1.4] ([109.100.236.15]) by mx.google.com with ESMTPSA id a4sm98120317eez.0.2013.07.14.16.15.02 for <ietf-http-wg@w3.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 16:15:03 -0700 (PDT)
Message-ID: <51E330F5.6050100@gmail.com>
Date: Mon, 15 Jul 2013 02:15:01 +0300
From: M Stefan <mstefanro@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ietf-http-wg@w3.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=209.85.215.174; envelope-from=mstefanro@gmail.com; helo=mail-ea0-f174.google.com
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UyVVp-0005y3-PM 8e08215edb7d23d84955ae8feb554956
X-Original-To: ietf-http-wg@w3.org
Subject: Authentication over HTTP
Archived-At: <http://www.w3.org/mid/51E330F5.6050100@gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18772
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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
- Authentication over HTTP M Stefan
- Re: Authentication over HTTP J Ross Nicoll
- Re: Authentication over HTTP Poul-Henning Kamp
- Re: Authentication over HTTP Yoav Nir
- Re: Authentication over HTTP Henry Story
- Re: Authentication over HTTP Poul-Henning Kamp
- Re: Authentication over HTTP Yoav Nir
- Re: Authentication over HTTP Nicolas Mailhot
- Re: Authentication over HTTP Ludin, Stephen
- Re: Authentication over HTTP Henry Story
- Re: Authentication over HTTP J Ross Nicoll
- Re: Authentication over HTTP Adrien W. de Croy
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Henry Story
- Re: Authentication over HTTP Josh Howlett
- Re: Authentication over HTTP Amos Jeffries
- Re: Authentication over HTTP Bjoern Hoehrmann
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Amos Jeffries
- Re: Authentication over HTTP David Morris
- Re: Authentication over HTTP Amos Jeffries
- Re: Authentication over HTTP Yoav Nir
- Re: Authentication over HTTP Albert Lunde
- Re: Authentication over HTTP Nicolas Mailhot
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Amos Jeffries
- Re: Authentication over HTTP Nico Williams
- Re: Authentication over HTTP Nicolas Mailhot
- Re: Authentication over HTTP Adrien W. de Croy