Dos and Don'ts of Client Authentication on the Web
{LANG_NAVORIGIN} Authentication
By: Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster, 02/26/2005
Abstract
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 store fronts. These
weaknesses often result from careless use of authenticators within Web
cookies. Of the twenty-seven sites we investigated, we weakened
the client authentication on two systems, gained unauthorized
access on eight, and extracted the secret key used to mint
authenticators from one.
We provide 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.
We propose a set of hints for designing a secure client authentication
scheme. Using these hints, we present the design and analysis of a
simple authentication scheme secure against forgeries by
the interrogative adversary. In conjunction with SSL, our scheme is
secure against forgeries by the active adversary.
1 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. We
observed this in an informal survey of authentication mechanisms used
by various popular Web sites. Of the twenty-seven sites we
investigated, we weakened the client authentication of two systems,
gained unauthorized access on eight, and extracted 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. We also found that many Web sites
would 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.
Our 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. We call 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.
We 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, we describe the limitations,
requirements, and security models to consider in designing Web client
authentication. Using these descriptions, we codify the
principles underlying the strengths and weaknesses of existing systems
as a set of hints in Section 3. As an example, we design
a simple and flexible authentication scheme in
Section 4. We implemented this scheme and analyzed its
security and performance; we present these findings in
Sections 5 and 6.
Section 7 compares the work in this paper to prior and
related work. We conclude with a summary of our results in
Section 8.
2 Security models and definitions
Clients want to ensure that only authorized people can access and
modify personal information that they share with Web sites.
Similarly, Web sites want to ensure that only authorized users have
access to the services and content it provides. Client authentication
addresses the needs of both parties.
Client authentication involves proving the identity of a
client
(or user) to a
server on the Web. We will use the term
``authentication'' to refer to this problem. Server authentication,
the task of authenticating the server to the client, is also important
but is not the focus this paper.
In this section, we present an overview of the security models and
definitions relevant in client authentication. We begin by describing
the practical limitations of a Web authentication system. This is
followed by a discussion of common requirements. We then characterize
types of breaks and adversaries.
2.1 Practical limitations
Web authentication is primarily a practical problem of deployability,
user acceptability, and performance.
Deployability
Web authentication protocols differ from traditional authentication
protocols in part because of the limited interface offered by the Web.
The goal is to develop an authentication system by using the protocols
and technologies commonly available in today's Web browsers and
servers. Authentication schemes for the Internet at large cannot rely
on technology not widely deployed. For example, Internet kiosks today
do not have smart card readers. Similarly, home consumers currently
have little incentive to purchase smart card readers or other hardware
token systems.
The client generally speaks to the server using the Hypertext Transfer
Protocol (HTTP [14]). This may be spoken over any transport
mechanism but is typically either TCP or SSL. Since HTTP is a
stateless, sessionless protocol, the client must provide an
authentication token or
authenticator with each request.
Computation allows the browser to transform inputs before sending them
to the server. This computation may be in a strictly defined manner,
such as in HTTP Digest authentication [16] and SSL, or it
may be much more flexible. Flexible computation is available via
Javascript, Java, Tcl, ActiveX, Flash, and Shockwave. Depending on the
application, these technologies could perhaps assist in the
authentication process. However, most of these technologies have high
startup overhead and mediocre performance. As a result, users may
choose to disable these technologies. Also, these extensions may not
be available on all operating systems and architectures. Any standard
authentication scheme should be as portable and lightweight as
possible, and therefore require few or no browser extensions. Thus for
today's use, any authentication scheme should avoid using client
computation for deployability reasons. If absolutely necessary,
Javascript and Java are commonly supported.
Client state allows the client's browser to store and reuse
authenticators. However, storage space may be very limited. In the
most limited case, the browser can only store passwords associated
with realms (as in HTTP Basic authentication [16]). A more
flexible form of storage which is commonly available in browsers is
the cookie [25,32]. Cookies allow a server store a
value on a client. In subsequent HTTP requests, the client
automatically includes the cookie value. A number of attributes can
control how long cookies are kept and to which servers they are
sent. In particular, the server may request that the client discard
the cookie immediately or keep it until a specified time. The server
may also request that the client only return the cookie to certain
hosts, domains, ports, URLs, or only over secure transports. Cookies
are the most widely deployed mechanism for maintaining client state.
User acceptability
Web sites must also consider user acceptability. Because sites want
to attract many users, the client authentication must be as
non-confrontational as possible. Users will be discouraged by schemes
requiring work such as installing a plug-in or clicking away dialog
boxes.
Performance
Stronger security protocols generally cost more in performance.
Service providers naturally want to respond to as many requests as
possible. Cryptographic solutions will usually degrade server
performance. Authentication should not needlessly consume valuable
server resources such as memory and clock cycles. With current
technology, SSL becomes unattractive because of the computational cost
of its initial handshaking.
2.2 Server security requirements
The goals of a server's authentication system depend on the strength
and granularity of authentication desired. Granularity refers to the
fact that some servers identify individual users throughout a session,
while others identify users only during the first request. A
fine-grained system is useful if specific authorization or
accountability of a user is required. A coarse-grained system may be
preferred in situations where partial user anonymity is desired.
A simple example of a coarse-grained service is a
subscription
service [42]. Subscription services merely
wish to verify that a user has paid for the service before allowing
access to read-only content. During the initial request, a user could
authenticate with a username and password. Unless the service allows
customization, subsequent requests need only verify that a user has
been authenticated without knowing the user's actual identity. A
trusted third party could handle the initial authentication of a user.
Some specific examples of sites that only require this level of
authentication are newspapers (e.g., WSJ.com), online libraries
(e.g., acm.org), and adult entertainment (e.g., playboy.com).
However, most sites customize the data sent back to users. This
naturally requires a fine-grained system. Each user must be identified
specifically to use their preferences. Examples of this
include sites that allow users to customize look-and-feel (e.g.,
slashdot.org), sites that filter information on behalf of the
user (e.g., infobeat.com), or sites which provide online
identities (e.g., hotmail.com).
2.3 Confidentiality and privacy
Confidentiality is not strictly related to authentication but it
is worth mentioning as well, since it can be provided by cryptography
and since it is often confused with authentication. A system that
provides confidentiality protects traffic from disclosure by anyone
except the sender and recipient. In contrast, a system that provides
authentication ensures that the person sending or
receiving the data is indeed who they claim to be. This may be
confusing because SSL, the only widely deployed mechanism for
providing confidentiality of HTTP transactions, provides options for
both authentication and confidentiality.
The distinction between confidentiality and
authentication is further blurred by the practice of current browsers of
displaying a single padlock whose meaning is ambiguous.
Typically, servers choose to provide confidentiality for only certain
special data by using SSL. For example, financial data require
confidentiality. Sites that deal with such information,
online brokerages , may be auction sites (e.g., ebay.com), banks and other financial service providers (e.g., etrade.com), or online
merchants (e.g., FatBrain.com).
Another issue commonly associated with authentication is user
privacy . Privacy refers to protecting the data available on the
server from access by unauthorized parties. While often the
information provided by the server is not itself secret, one does not
usually want unknown parties discovering their personal interests.
For example, a user may sign up to see discount airfares to San
Francisco or select stocks in a portfolio for updated stock quotes.
While the fact that US Airways is offering a low fare or that Cisco
stock has shed four points is not in any way secret, it may be telling
to find out if a particular user is interested in that
information. Therefore servers often need to provide ways to keep
personalized data private. Privacy can be achieved by using secure
authentication and providing confidentiality.
2.4 Breaks
An adversary's goal is to break an authentication scheme faster than
by brute force. Here we use terminology loosely borrowed from
cryptography to characterize the kinds of breaks an adversary can
achieve [19,31].
In an
existential forgery , the adversary can forge an
authenticator for at least one user. However, the adversary cannot
choose the user. This may be most interesting in the case where
authenticators protect access to a subscription service. While an
existential forgery would not give an adversary access to a chosen
user's account, it would allow the adversary to access content without
paying for it. This is the least harmful kind of forgery.
In a
selective forgery , the adversary can forge an
authenticator for a particular user. This adversary can access any
chosen user's personalized content, be it Web e-mail or bank
statements.
Note that a forgery implies the construction of a new authenticator,
not one previously seen. In a traditional
replay attack , the
adversary is merely reusing a captured authenticator.
Finally, a
total break results in recovery of the secret key
used to mint authenticators. This is the most serious break in that it
allows the adversary to construct valid authenticators at any time for
all users.
2.5 Adversaries
We consider three kinds of adversaries that attack Web authentication
protocols: the
interrogative adversary , the
eavesdropping
adversary , and the
active adversary . Each successive
adversary possesses all the abilities of the weaker adversaries. Note
that our definitions differ somewhat from tradition. Our adversaries
gather information and apply this information to achieve a break. The
adversaries differ from each other only in their information gathering
ability.
Interrogative adversary
The
interrogative adversary can make a reasonable number of
queries of a Web server. It can adaptively choose its next query
based on the answer to a previous query. We named this the
interrogative adversary because the adversary makes many queries, but
lacks the ability to sniff the network.
The ability to make queries is surprisingly powerful. The adversary
can pass attempted forgeries to the server's verification routine. By
creating new accounts on a server, the adversary can obtain the
authenticator for many different usernames. This is
possible on any server that allows account creation without some form
of out-of-band authentication (e.g., credit cards) to throttle
requests. In this paper we assume no such throttle exists.
The interrogative adversary can also use information publicly
available on the server. A server may publish the usernames of valid
account holders, perhaps in a public discussion forum. An adversary
attacking this server might find this list useful.
In more theoretical terms, the interrogative adversary may treat the
server as an oracle. An interrogative adversary can carry out an
adaptive chosen message attack by repeatedly asking for the
server to mint or verify authenticators [19].
Eavesdropping adversary
The
eavesdropping adversary can see all traffic between users
and the server, but cannot modify any packets flowing across
the network. That is, the adversary
can sniff the network and replay authenticators. This
adversary also has all the abilities of the interrogative adversary.
An eavesdropping adversary can apply its sniffed
information to attempt a break. Computer systems research would
consider this an active attack; we do not. This style of definition
is more common in the theory community where attacks consist of an
information gathering process, a challenge, another optional
information gathering process, and then an attempted
break [3].
Active adversary
The
active adversary can in addition see and modify all traffic
between the user and the server. This adversary can mount
man-in-the-middle attacks. In the real world, this situation might
arise if the adversary controls a proxy service between the user and
server.
E-Mail Link
Your IP address will be sent with this e-mail
