[NEWS] The Dos and Don'ts of Client Authentication on the Web

From: support@securiteam.com
Date: 09/11/01


From: support@securiteam.com
To: list@securiteam.com
Subject: [NEWS] The Dos and Don'ts of Client Authentication on the Web
Message-Id: <20010911080402.9706A138C0@mail.der-keiler.de>
Date: Tue, 11 Sep 2001 10:04:02 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  The Dos and Don'ts of Client Authentication on the Web
------------------------------------------------------------------------

SUMMARY

Client authentication has been a continuous source of problems on the Web.
Although many well-studied techniques exist for authentication, Web sites
continue to use extremely weak authentication schemes, especially in
non-enterprise environments such as storefronts. These weaknesses often
result from careless use of authenticators within Web cookies. An MIT
research paper shows that of twenty-seven sites that were investigated, it
was possible to weaken the client authentication on two systems, gained
unauthorized access on eight, and extracted the secret key used to mint
authenticators from one.

The research provides a description of the limitations, requirements, and
security models specific to Web client authentication. This includes the
introduction of the interrogative adversary, a surprisingly powerful
adversary that can adaptively query a Web site.

The article proposes a set of hints for designing a secure client
authentication scheme. Using these hints, the article presents the design
and analysis of a simple authentication scheme secure against forgeries by
the interrogative adversary. In conjunction with SSL, the proposed scheme
is secure against forgeries by the active adversary.

The technical report includes details not released in the USENIX
proceedings.

DETAILS

Introduction:
Client authentication is a common requirement for modern Web sites as more
and more personalized and access-controlled services move online.
Unfortunately, many sites use authentication schemes that are extremely
weak and vulnerable to attack. These problems are most often due to
careless use of authenticators stored on the client. The article observes
this in an informal survey of authentication mechanisms used by various
popular Web sites. Of the twenty-seven sites the article investigated, the
article describes the weakening of the client authentication of two
systems, gaining of unauthorized access on eight, and extraction of the
secret key used to mint authenticators from one.

This is perhaps surprising given the existing client authentication
mechanisms within HTTP [16] and SSL/TLS [11], two well-studied mechanisms
for providing authentication secure against a range of adversaries.
However, there are many reasons that these mechanisms are not suitable for
use on the Web at large. Lack of a central infrastructure such as a
public-key infrastructure or a uniform Kerberos [41] contributes to the
proliferation of weak schemes. The article also talks about that many Web
sites design their own authentication mechanism to provide a better user
experience. Unfortunately, designers and implementers often do not have a
background in security and, as a result, do not have a good understanding
of the tools at their disposal. Because of this lack of control over user
interfaces and unavailability of a client authentication infrastructure,
Web sites continue to reinvent weak home-brew client authentication
schemes.

The authors' goal is to provide designers and implementers with a clear
framework within which to think about and build secure Web client
authentication systems. A key contribution of this paper is to realize
that the Web is particularly vulnerable to adaptive chosen message
attacks. The article calls an adversary capable of performing these
attacks an interrogative adversary. It turns out that for most systems,
every user is potentially an interrogative adversary. Despite having no
special access to the network (in comparison to the eavesdropping and
active adversary), an interrogative adversary is able to significantly
compromise systems by adaptively querying a Web server. The authors of the
article believe that, at a minimum, Web client authentication systems
should defend against this adversary. However, with this minimum security,
sites may continue to be vulnerable to attacks such as eavesdropping,
server impersonation, and stream tampering. Currently, the best defense
against such attacks is to use SSL with some form of client
authentication; see Rescorla [37] for more information on the security and
proper uses of SSL.

In Section 2, the article describes the limitations, requirements, and
security models to consider in designing Web client authentication. Using
these descriptions, the authors of the article codify the principles
underlying the strengths and weaknesses of existing systems as a set of
hints in Section 3. As an example, the authors of the article design a
simple and flexible authentication scheme in Section 4. The articles talks
about the implementation of this scheme and its security analysis and
performance; the article presents these findings in Sections 5 and 6.
Section 7 compares the work in this paper to prior and related work. The
article concludes with a summary of the results in Section 8.

ADDITIONAL INFORMATION

The complete paper can be viewed at:
 <http://cookies.lcs.mit.edu/pubs.html>
http://cookies.lcs.mit.edu/pubs.html

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages

  • Re: VPNing with L2TP/IPSec
    ... Technically the RRAS doesn't need a server authentication certificate, ... failure even though a client authentication certificate exists. ...
    (microsoft.public.isa.vpn)
  • Re: client authentication
    ... The Client Authentication box will only pop up if the website is using Basic ... Authentication or Windows Authentication. ... > side application (a Browser Helper Object - if that helps any). ...
    (microsoft.public.inetserver.iis.security)
  • multi domain
    ... I have some problem in setting up krb5.conf for client authentication. ... Principals that belongs to A.COMPANY.COM are authenticated (kinit ... For those who are not authenticated kinit returns "Client not found in ...
    (comp.protocols.kerberos)
  • Re: Authentification vs Encryption in a system to system interface
    ... > While the above is true, the persons in the original article ... > appeared to be discussing Client Authentication and Authorization ... > rather than Server Authentication. ...
    (comp.security.misc)
  • Solaris Security Summary
    ... Administering Security on the Solaris OE ... Configuration control, facility management, and system ... Authentication: The ability to prove who you are. ...
    (comp.unix.solaris)