Re: Authentication over HTTP

Hello Stefan,

Most of this is a UI challenge, and therefore arguably beyond the remit 
of this group. The W3C Web Application Security Group ( 
http://www.w3.org/2011/webappsec/ ) is probably a more appropriate place 
for this. I do want to provide feedback, but I'm going to keep my 
response short, so apologies for abruptness.

StartSSL ( http://www.startssl.com/?app=1 ) will provide free 
certificates. It's been argued that processor overhead isn't a major 
concern at this point, although that's not something I've tested myself. 
Server Name Indication client support is limited, however, so the 
requirement for an IP address per certificate is essentially still in 
effect. That does limit adoption.

I'm not sure what your suggested shared secret approach would do that 
HTTP Digest Authentication (see http://tools.ietf.org/html/rfc2617 ) 
doesn't? Personally I also am not a fan of anything which requires the 
server to be able to retrieve the plaintext of the shared secret; 
inevitably it's a security hole, and given the rate at which systems are 
compromised it's difficult for me to accept it as reasonable.

By comparison, client certificate based authentication has significant 
advantages in terms of inability for phishing attacks to work (the 
original value is never transmitted) and in resistance to server-side 
compromises. However there are usability issues in terms of generating 
keys with appropriate certificates, managing when certificates are 
presented (such as not to make it incredibly easy to track users), and 
making certificate backup easy to use. Also in handling access when away 
from your normal desktop (for example in a cyber cafe).

Ross

On 15/07/2013 00:15, M Stefan wrote:
> 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
>

Received on Sunday, 14 July 2013 23:52:23 UTC