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
4 Design
In this section we present a scheme for performing client
authentication. This design is intended to be an example of a simple
system that follows the hints provided in Section 3. We
do not claim that the scheme is novel, but we do claim that the
concepts and design process are not extensively discussed in
literature. We present a brief security analysis of the schemes in
Section 5.
Our scheme provides a personalizable authenticator which allows the
server to statelessly verify the authenticity of the request and its
contents. The server can explicitly control the valid lifetime of the
authenticator as well. The authenticator can include all the
information needed to service a request, or can be used as a key to
refer to session information stored on the server.
The overall operation of this scheme is shown in
Figure 2. We assume that the user has an existing
account on the server which is accessed via a username and password.
At the start of each session, the server receives the username and
password, verifies them, and sets an authentication cookie on the
user's machine. Since cookies are widely supported, this makes the
system portable. Subsequent requests to the server include this cookie
and allow the server to authenticate the request. The design of each
cookie ensures that a valid cookie can only be created by the server;
therefore anyone possessing a valid cookie is authorized to access the
requested content on the server.
Our scheme is designed to be secure against an interrogative
adversary, as we believe that most of the schemes we evaluated were
designed with this type of adversary in mind. However, because SSL
with server authentication provides confidentiality and integrity,
layering our design on top of SSL can provide an authentication
system secure against an active adversary.
4.1 Cookie Recipe
The recipe for our cookie follows easily from the hints presented in
Section 3. We create an unforgeable authenticator that
includes an explicit expiration time. We use HTTP state (i.e. cookies)
to store this authenticator with the client. The value of this cookie
is shown here:
exp=t&data=s&digest=MAC
k(exp=t&data=s)
The expiration time is denoted
t and is expressed as seconds past
1970 GMT. The data string
s is an optional parameter denoting
arbitrary data that the server wishes to associate with the client.
Finally, the cookie includes a MAC for the cleartext expiration and
data.
Our cookie requires the use of a
non-malleable MAC; that is,
one where it is intractable to generate a valid ciphertext from a
plaintext message related to a plaintext message with a known
ciphertext [12,24]. That is, no adversary
can generate a valid ciphertext without both the server's secret key
and the plaintext, no matter how many samples of valid
plaintext/ciphertext pairs the adversary has. Examples of keyed,
non-malleable MACs are HMAC-MD5 and HMAC-SHA1 [24].
4.2 Discussion
Selecting an expiration time
t is a trade-off between limiting the
damage that can be done with a leaked authenticator and requiring the
user to reauthenticate. Yahoo!, for example, allows users to specify
what expiration interval they prefer for authenticators that control
access to sensitive data [47]. This allows the user to control
the trade-off. On the other hand, for insensitive data, it makes sense
for the server to make the choice. For example, a newspaper might want
cookies to be valid for only a day, whereas a magazine might allow
sessions to be valid for a month (as if the user were buying a single
issue).
The value
s may be any information specific to the user that the
server wishes to access without maintaining server state. This may be
anything from a session identifier to a username. Beware that this
data is not encrypted so sensitive information should not be stored
here; if sensitive data is needed, we recommend that a
cryptographically random session identifier be used. This will prevent
information leaks from compromising a user's privacy. On the other
hand, if sensitive user information is required to handle only a small
percentage of the content requests, the authenticator can contain the
information needed to service the majority of requests. This way the
server can avoid doing a possibly expensive look-up with every
request.
A server may also choose to leave
s empty (and removing the
data parameter from the cookie). This might be useful in the
case where authentication must expire, but all users are
essentially the same. A plausible example of this might be a pay-per
use service, such as a newspaper.
4.3 Authentication and revocation
To authenticate a user, the server retrieves the cookie and extracts
the expiration. If the cookie has not expired, the server recalculates
the MAC in the
digest parameter of the cookie. Since the
server is the only entity who knows the key
k, the properties of the
MAC function imply that a valid cookie was generated by the
server. So long as the server only generates cookies for authenticated
users, any client with a valid cookie is a valid user.
This scheme does not provide a mechanism for secure
revocation ;
that is, ending the user's session before the expiration time is up.
The easiest option is for the server can instruct the client to
discard the authentication cookie. This will usually be adequate for
most applications. However, a client who has saved the value of the
cookie can continue to reuse that value so long as the explicit
expiration time has not yet passed.
In most cases, a short session can make revocation unnecessary: the
user can access the server until the session expires, at which time
the server can refuse to issue a new authenticator. Servers that
require secure revocation should keep track of the session status on
the server (e.g., using a random session key or our personalized
scheme with a server database). This session can then be explicitly
revoked on the server, without trusting the client.
The scheme does allow simultaneous revocation of all authenticators,
which can be accomplished by rotating the server key. This will
cause all outstanding cookies to fail to verify. Thus, all
users will have to log in again. This might be useful for finding
unused accounts.
4.4 Design alternatives
One interesting point of our scheme is that we have included the
expiration time
t in the cookie value itself. This is the only way
for a server to have access to the expiration date without maintaining
state. Explicit inclusion of the expiration date in a non-malleable
cookie provides fixed-length sessions without having to trust the
client to expire the cookie. It would also have been possible to
merely use a session identifier but that would always require server
state and might lead to mistakes where expiration was left in the
hands of the client.
Many schemes do involve setting a random session identifier for each
user. This session identifier is used to access the user's session
information, which is stored in a database on the server. While such a
scheme allows for a client to make customizations (i.e. it is
functionally equivalent to the scheme we have presented), it is
potentially subject to guessing attacks on the session identifier
space. If an adversary can successfully guess a session identifier,
the system is broken (see Section 3.3). Our
scheme provides a means for authenticating clients that is resistant
to guessing attacks on session identifiers. Furthermore, our scheme
provides the option of authenticating clients with
O(1) server
state, rather than
O(
n), where
n is the number of clients.
Our system can also make it easier to deploy multi-server systems.
Using session identifiers requires either synchronized, duplicated
data between servers or a single server to coordinate requests, which
becomes a potential bottleneck. Our scheme allows any server to
authenticate any user with a minimum of information, none of which
must be dynamically shared between servers. In addition, the
authentication always completes in constant time, rather than in time
which increases with the number of users.
5 Security analysis
In this section we present an informal analysis of the security
properties of our design. For the purpose of discussion, we will refer
to the cookie's two halves: the
plaintext and the
verifier . The plaintext is the expiration concatenated with
the user string, and the verifier is the HMAC of the plaintext.
We will discuss the security of the scheme once the authenticator
(i.e. cookie) is received by the user from the server. We will not
discuss mechanisms for completing the initial login.
5.1 Forging authenticators
An adversary does not need to log in if it can create a valid
authenticator offline. Often an adversary can create a plausible
plaintext string; therefore the security of the authenticator rests on
the fact that the verifier cannot be calculated by an adversary
without the key. Since we have selected our MAC to be
non-malleable, an adversary can not forge a new authenticator.
An attacker may also attempt to extend the capabilities associated
with the authenticator. This might include changing the expiration
date or some aspect of the data string which would allow unauthorized
access to the server. For instance, if the data string includes a
username, and the adversary can alter the username, this might allow
access another user's account. It is easy enough for the adversary to
change the plaintext of the authenticator in the desired manner.
However, as we have seen, because HMAC is non-malleable, it is
intractable for the adversary to generate a valid ciphertext for an
altered plaintext string. Therefore the adversary cannot bring about
any change in an authenticator that will be accepted by the server.
5.2 Authenticator hijacking
An interrogative adversary cannot see any messages that pass between
the user and the server. Therefore, it cannot hijack another user's
authenticator. However, an eavesdropper can see the authenticator as
it passes between the user and the server. Such an adversary can
easily perform a replay attack. Therefore the system is vulnerable to
hijacking by such an adversary. However, the replay attack lasts only
as long as the authenticator is valid; that is, between the time the
adversary ``sniffs'' the authenticator and the expiration time. The
adversary does not have the ability to create or modify a valid
authenticator. Therefore this is an attack of limited usefulness. The
lifetime of the authenticator determines how vulnerable the system is;
systems which employ a shorter authenticator lifetime will have to
reauthenticate more often, but will have tighter bounds on the damage
that a successful eavesdropping adversary can accomplish. In addition, the
system can protect against an eavesdropping adversary by using SSL to
provide confidentiality for the authenticator.
5.3 Other attacks
We mention briefly some attacks on our schemes which do not deal with
the authenticator directly. The best known attack against the scheme in
Section 4 is a brute force key search.
A server compromise breaks the system: if the adversary obtains the
key to the MAC, it can generate valid authenticators for all
users. Random keys and key rotation help to prevent the adversary from
mounting brute force key attacks (see
Lenstra [28] for suggestions on key size).
In addition, key rotation helps protect against volume attacks,
whereby an adversary may be able to obtain the key to the hash
function because the adversary has obtained a great quantity of data
encrypted using it. We note that HMAC-MD5 and HMAC-SHA1 are not
believed to be vulnerable to this type of analysis
[24]. However, we believe that it is prudent to include key
rotation since it does not decrease the security of the scheme, it
protects against server compromise, and it has minimal cost to the
server.
In addition, the adversary can obtain unauthorized access by
guessing the user's password; see
Section 3.2 for some guidelines for
preventing this.
Our scheme in itself only provides user authentication. For protection
against server impersonation or for data integrity, we recommend SSL.
E-Mail Link
Your IP address will be sent with this e-mail
