• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
A Secure Cookie Protocol
Alex X. Liu
1
, Jason M. Kovacs
Department of Computer SciencesThe University of Texas at AustinAustin, Texas 78712-0233, U.S.A.
{
alex, jmkovacs
}
@cs.utexas.edu
Chin-Tser Huang
Dept. of Computer Science and EngineeringUniversity of South CarolinaColumbia, South Carolina 29208, U.S.A.
huangct@cse.sc.edu
Mohamed G. Gouda
Department of Computer SciencesThe University of Texas at AustinAustin, Texas 78712-0233, U.S.A.
gouda@cs.utexas.edu
Abstract
Cookies are the primary means for web applicationsto authenticate HTTP requests and to maintain clientstates. Many web applications (such as electronic com-merce) demand a secure cookie protocol. Such a pro-tocol needs to provide the following four services: au-thentication, confidentiality, integrity and anti-replay.Several secure cookie protocols have been proposed inprevious literature; however, none of them are com-pletely satisfactory. In this paper, we propose a securecookie protocol that is effective, efficient, and easy todeploy. In terms of effectiveness, our protocol providesall of the above four security services. In terms of ef-ficiency, our protocol does not involve any databaselookup or public key cryptography. In terms of deploy-ability, our protocol can be easily deployed on an exist-ing web server, and it does not require any change tothe Internet cookie specification. We implemented oursecure cookie protocol using PHP, and the experimen-tal results show that our protocol is very efficient.
1. Introduction
The widely used HTTP (Hypertext Transfer Proto-col) works in a request-response fashion. First, a clientsends a request (which either asks for a file or invokesa program) to a server. Second, the server processesthe request and sends back a response to the client.After this, the connection between the client and theserver is dropped and forgotten. HTTP is stateless inthat an HTTP server treats each request independentlyof any previous requests. However, many web applica-tions built on top of HTTP need to be stateful. For ex-ample, most online shopping applications need to keeptrack of the shopping carts of their clients.
1 Alex X. Liu is the corresponding author of this paper.
Web applications often use cookies to main-tain state. A cookie is a piece of information thatrecords the state of a client. When a server needs to re-member some state information for a client, the servercreates a cookie that contains the state informa-tion and sends the cookie to the client. The client thenstores the cookie either in memory or on a hard disk.The client later attaches the cookie to every subse-quent request to the server.Many web applications (such as electronic com-merce) demand a secure cookie protocol. A securecookie protocol that runs between a client and a serverneeds to provide the following four services: authenti-cation, confidentiality, integrity and anti-replay.1.
Authentication
: A secure cookie protocol shouldallow the server to verify that the client has beenauthenticated within a certain time period. More-over, any client should not be able to forge a validcookie.In secure web applications, a typical sessionbetween a client and a server consists of twophases. The first phase is called the
loginphase
andthe second phase is called the
subsequent-requestsphase
.
Login Phase
: In this phase, the client and theserver mutually authenticate each other. On onehand, the client authenticates the server using theserver’s PKI (Public Key Infrastructure) Certifi-cate after he establishes an SSL (Secure SocketsLayer) connection with the server. On the otherhand, the server authenticates the client using theclient’s user name and password, and sends a se-cure cookie (which is also called an “authentica-tion token” or an “authenticator” in previous lit-erature) to the client.
Subsequent-requests Phase
: In this phase, theclient sends the secure cookie along with every re-quest to the server; the server verifies whether thecookie is valid, and if it is, services the request.
 
2.
Confidentiality
: The contents of a secure cookieis intended only for the server to read. There aretwo levels of confidentiality that a secure cookieprotocol may achieve: low-level confidentiality andhigh-level confidentiality.(a)
Low-level Confidentiality 
: A secure cookieprotocol with low-level confidentiality pre-vents any parties except the server and theclient from reading the contents of a cookie.To achieve low-level confidentiality, a se-cure cookie protocol usually runs on top of SSL. Note that SSL encrypts every mes-sage between the client and the server us-ing a session key that only the client andthe server know. In this paper, we as-sume that any secure cookie protocol runson top of SSL.(b)
High-level Confidentiality 
: A secure cookieprotocol with high-level confidentiality pre-vents any parties except the server from read-ing the sensitive information within a cookiethat the server does not want to reveal to theclient [8]. For example, the cookie’s contentsmay contain some client information such astheir internal rating or credit score, which theserver may not want the client to be aware of.Different web applications may require differentlevels of confidentiality. Therefore, a secure cookieprotocol should be able to support either low-levelconfidentiality or high-level confidentiality config-urations.3.
Integrity
: A secure cookie protocol should allowa server to detect whether a cookie has been mod-ified.4.
Anti-replay
: In the case that an attacker replaysa stolen cookie, a secure cookie protocol should beable to detect that the cookie is invalid. Other-wise, the attacker would be authenticated as theclient that the replayed cookie was issued to.In designing a secure cookie protocol, besides theabove security requirements, we also need to considerthe issues of efficiency and deployability. As for effi-ciency concerns, a secure cookie protocol should avoidrequiring a server to do database lookups in verifyinga cookie, and should avoid public key cryptography.Note that database lookups dramatically slow downthe speed that a server takes to verify a cookie. As fordeployability concerns, a secure cookie protocol shouldavoid requiring a client to possess a public key and aprivate key, which is currently impractical to assume.Several cookie protocols have been proposed [2,5,8,10]; however, none of these protocols are completelysatisfactory. The cookie protocol in [5] has three weak-nesses: it does not have a mechanism for providinghigh-level confidentiality, it is vulnerable to cookie re-play attacks, and its mechanism for defending againstvolume attacks is inefficient and non-scalable. Thethree authentication mechanisms of the cookie proto-col in [8] are either ineffective or difficult to deploy. Thecookie protocols in [2] and [10] are inefficient becausethey require database lookups in verifying a cookie.In this paper, we propose a secure cookie protocolthat is effective, efficient, and easy to deploy. In termsof effectiveness, our secure cookie protocol provides allof the above four security services. In terms of effi-ciency, our secure cookie protocol does not involve anydatabase lookup or public key cryptography. In termsof deployability, our secure cookie protocol can be eas-ily deployed on an existing web server, and it does notrequire any change to the current Internet cookie spec-ification [7].The rest of this paper proceeds as follows. In Sec-tion 2, we present our secure cookie protocol in detail.In Section 3, we discuss the implementation of our se-cure cookie protocol and its performance. In Section 4,we review and examine existing cookie protocols. Wegive concluding remarks in Section 5.
2. Secure Cookie Protocol
The state of the art of secure cookie protocols is theone presented by Fu et al. in [5]. In this section, we firstexamine this protocol, which we refer as
Fu’scookiepro-tocol 
. We show that this protocol has three major prob-lems, and we give a solution to each of them. Finally,we present our secure cookie protocol. The notationsused in this section are listed in the following table.
|
Concatenation
HMAC 
(
m,k
) Keyed-Hash Message AuthenticationCode of message
m
using key
ksk
Server Key(
m
)
k
Encryption of message
m
using key
k
Table 1: NotationsThe keyed-hash message authentication codes usedin this paper are assumed to be
verifiable
and
non-malleable
: given a message
m
and a key
k
, it is com-putationally cheap to compute
HMAC 
(
m,k
); however,given
HMAC 
(
m,k
), it is computationally infeasibleto compute the message
m
and the key
k
. Examplesof such keyed-hash message authentication codes areHMAC-MD5 and HMAC-SHA1 [1,4,6,9].The server key (i.e.,
sk
) of a server is a secret keythat only the server knows.
 
2.1. Fu’s Cookie Protocol
Fu’s cookie protocol is shown in Figure 1.user name
|
expiration time
|
data
|
HMAC( user name
|
expiration time
|
data,
sk
)
Figure 1. Fu’s Cookie Protocol
In this cookie protocol, a secure cookie that is issuedby a server to a client consists of the following four sub-fields within the cookie value field of the HTTP cookiespecification.1.
User Name
: The value of this field uniquely iden-tifies a user.2.
Expiration Time
: The value of this field, which isexpressed as seconds past 1970 GMT, indicateswhen this cookie will expire and the server shouldreject it from a client.3.
Data 
: The value of this field can be anything thatthe server wants to remember for the client whenthe cookie is created. The state information (suchas the contents of an online shopping cart) of thecommunication between the client and the serveris usually stored in this field.4. Keyed-Hash Message Authentication Code(HMAC): The value of this field is the keyed-hashmessage authentication code of the above threefields using the server key.Fu’s cookie protocol has three major security weak-nesses. First, it does not have a mechanism for provid-ing high-level confidentiality. Second, it is vulnerableto cookie replay attacks. Third, its mechanism for de-fending against volume attacks is inefficient and non-scalable. Next, we detail these three weaknesses andgive an efficient and secure solution to each of them.
2.2. Problem I: Cookie Confidentiality
We have discussed that some web applications needhigh-level confidentiality for their cookies. To pro-vide high-level confidentiality, a secure cookie proto-col should encrypt the data field of each cookie. Nowthe question is this: which key should a server use forthis encryption?Fu’s protocol does not provide an answer to thisquestion. There is only one key involved in Fu’s proto-col, namely the server key. One straightforward solu-tion is to use this server key to encrypt the data fieldof every cookie; however, this solution is not secure.An attacker can register as a legitimate client with aserver and then gather a large number of cookies is-sued by the server. If the data fields of all of thesecookies are encrypted by the same server key, the at-tacker could possibly discover this key using cryptanal-ysis. Although such cryptanalysis is hard, but, it is pru-dent to avoid any such possibility.The cookie protocol proposed in [10] manages cookiespecific encryption keys as follows. A server maintains adatabase that stores the user name and the encryptionkey of every client. When a server creates a cookie fora client, the server generates a new random key for en-crypting the cookie and replaces the old encryption keyassociated with the client in the database with this newkey. When a server receives an encrypted cookie froma client, the server uses the user name of the client tosearch in the database for the corresponding encryp-tion key. This solution has two major disadvantages.First, it is highly inefficient because of the overhead of database lookups. Second, when the old encryption keyof a client is deleted, all the cookies that are encryptedby the old encryption key become invalid. This couldbe very destructive. A client may attach the same en-crypted cookie to more than one request to a server.The server may create a new cookie and a new encryp-tion key for the client after the server receives the firstrequest, which results all the other requests with thesame cookie being denied by the server.The cookie protocol proposed in [8] manages cookiespecific encryption keys in a different way: when aserver creates a cookie of high-level confidentiality, theserver generates a random key, encrypts the key withthe server’s public key, and stores the encrypted key inthe cookie itself rather than a database on the serverside. The downside of this solution is the verificationof every cookie involves public key cryptography, whichmakes the cookie protocol complex and inefficient.Our solution to this problem is simple and efficient.We propose to use HMAC(user name
|
expiration time,sk) as the encryption key. This solution has the fol-lowing three good properties. First, the encryption keyis unique for each different cookie because of the username and expiration time. Note that whenever a newcookie is created, a new expiration time is included inthe cookie. Second, the encryption key is unforgeablebecause the server key is kept secret. Third, the encryp-tion key of each cookie does not require any storage onthe server side or within the cookie, rather, it is com-puted by a server dynamically.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...