ASecureCookieProtocol Alex X. Liu1, Jason M. Kovacs Chin-Tser Huang Mohamed G. Gouda Department of Computer Sciences Dept. of Computer Science and Engineering Department of Computer Sciences The University of Texas at Austin University of South Carolina The University of Texas at Austin Austin, Texas 78712-0233, U.S.A. Columbia, South Carolina 29208, U.S.A. Austin, Texas 78712-0233, U.S.A. {alex, jmkovacs}@cs.utexas.edu [email protected] [email protected] Abstract Web applications often use cookies to main- tain state. A cookie is a piece of information that Cookies are the primary means for web applications records the state of a client. When a server needs to re- to authenticate HTTP requests and to maintain client member some state information for a client, the server states. Many web applications (such as electronic com- creates a cookie that contains the state informa- merce) demand a secure cookie protocol. Such a pro- tion and sends the cookie to the client. The client then tocol needs to provide the following four services: au- stores the cookie either in memory or on a hard disk. thentication, confidentiality, integrity and anti-replay. The client later attaches the cookie to every subse- Several secure cookie protocols have been proposed in quent request to the server. previous literature; however, none of them are com- Many web applications (such as electronic com- pletely satisfactory. In this paper, we propose a secure merce) demand a secure cookie protocol. A secure cookie protocol that is effective, efficient, and easy to cookie protocol that runs between a client and a server deploy. In terms of effectiveness, our protocol provides needs to provide the following four services: authenti- all of the above four security services. In terms of ef- cation, confidentiality, integrity and anti-replay. ficiency, our protocol does not involve any database 1. Authentication: A secure cookie protocol should lookup or public key cryptography. In terms of deploy- allow the server to verify that the client has been ability, our protocol can be easily deployed on an exist- authenticated within a certain time period. More- ing web server, and it does not require any change to over, any client should not be able to forge a valid the Internet cookie specification. We implemented our cookie. secure cookie protocol using PHP, and the experimen- tal results show that our protocol is very efficient. In secure web applications, a typical session between a client and a server consists of two phases. The first phase is called the login phase and the second phase is called the subsequent-requests 1. Introduction phase. Login Phase: In this phase, the client and the The widely used HTTP (Hypertext Transfer Proto- server mutually authenticate each other. On one col) works in a request-response fashion. First, a client hand, the client authenticates the server using the sends a request (which either asks for a file or invokes server’s PKI (Public Key Infrastructure) Certifi- a program) to a server. Second, the server processes cate after he establishes an SSL (Secure Sockets the request and sends back a response to the client. Layer) connection with the server. On the other After this, the connection between the client and the hand, the server authenticates the client using the server is dropped and forgotten. HTTP is stateless in client’s user name and password, and sends a se- that an HTTP server treats each request independently cure cookie (which is also called an “authentica- of any previous requests. However, many web applica- tion token” or an “authenticator” in previous lit- tions built on top of HTTP need to be stateful. For ex- erature) to the client. ample, most online shopping applications need to keep Subsequent-requests Phase: In this phase, the track of the shopping carts of their clients. client sends the secure cookie along with every re- quest to the server; the server verifies whether the 1 Alex X. Liu is the corresponding author of this paper. cookie is valid, and if it is, services the request. 0-7803-9428-3/05/$20.00 ©2005 IEEE. 333 Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply. 2. Confidentiality: The contents of a secure cookie satisfactory. The cookie protocol in [5] has three weak- is intended only for the server to read. There are nesses: it does not have a mechanism for providing two levels of confidentiality that a secure cookie high-level confidentiality, it is vulnerable to cookie re- protocol may achieve: low-level confidentiality and play attacks, and its mechanism for defending against high-level confidentiality. volume attacks is inefficient and non-scalable. The (a) Low-level Confidentiality: A secure cookie three authentication mechanisms of the cookie proto- protocol with low-level confidentiality pre- col in [8] are either ineffective or difficult to deploy. The vents any parties except the server and the cookie protocols in [2] and [10] are inefficient because client from reading the contents of a cookie. they require database lookups in verifying a cookie. To achieve low-level confidentiality, a se- In this paper, we propose a secure cookie protocol cure cookie protocol usually runs on top of that is effective, efficient, and easy to deploy. In terms SSL. Note that SSL encrypts every mes- of effectiveness, our secure cookie protocol provides all sage between the client and the server us- of the above four security services. In terms of effi- ing a session key that only the client and ciency, our secure cookie protocol does not involve any the server know. In this paper, we as- database lookup or public key cryptography. In terms sume that any secure cookie protocol runs of deployability, our secure cookie protocol can be eas- on top of SSL. ily deployed on an existing web server, and it does not (b) High-level Confidentiality: A secure cookie require any change to the current Internet cookie spec- protocol with high-level confidentiality pre- ification [7]. vents any parties except the server from read- The rest of this paper proceeds as follows. In Sec- ing the sensitive information within a cookie tion 2, we present our secure cookie protocol in detail. that the server does not want to reveal to the In Section 3, we discuss the implementation of our se- client [8]. For example, the cookie’s contents cure cookie protocol and its performance. In Section 4, may contain some client information such as we review and examine existing cookie protocols. We their internal rating or credit score, which the give concluding remarks in Section 5. server may not want the client to be aware of. 2. Secure Cookie Protocol Different web applications may require different levels of confidentiality. Therefore, a secure cookie The state of the art of secure cookie protocols is the protocol should be able to support either low-level one presented by Fu et al. in [5]. In this section, we first confidentiality or high-level confidentiality config- examine this protocol, which we refer as Fu’s cookie pro- urations. tocol. We show that this protocol has three major prob- 3. Integrity: A secure cookie protocol should allow lems, and we give a solution to each of them. Finally, a server to detect whether a cookie has been mod- we present our secure cookie protocol. The notations ified. used in this section are listed in the following table. 4. Anti-replay: In the case that an attacker replays a stolen cookie, a secure cookie protocol should be | Concatenation able to detect that the cookie is invalid. Other- HMAC (m, k) Keyed-Hash Message Authentication wise, the attacker would be authenticated as the Code of message m using key k client that the replayed cookie was issued to. sk Server Key In designing a secure cookie protocol, besides the (m)k Encryption of message m using key k above security requirements, we also need to consider Table 1: Notations the issues of efficiency and deployability. As for effi- ciency concerns, a secure cookie protocol should avoid The keyed-hash message authentication codes used requiring a server to do database lookups in verifying in this paper are assumed to be verifiable and non- a cookie, and should avoid public key cryptography. malleable: given a message m and a key k,itiscom- Note that database lookups dramatically slow down putationally cheap to compute HMAC (m, k); however, the speed that a server takes to verify a cookie. As for given HMAC (m, k), it is computationally infeasible deployability concerns, a secure cookie protocol should to compute the message m and the key k. Examples avoid requiring a client to possess a public key and a of such keyed-hash message authentication codes are private key, which is currently impractical to assume. HMAC-MD5 and HMAC-SHA1 [1, 4, 6, 9]. Several cookie protocols have been proposed [2, 5, The server key (i.e., sk) of a server is a secret key 8, 10]; however, none of these protocols are completely that only the server knows. 334 Authorized licensed use limited to: Michigan State University. Downloaded on October 21, 2009 at 23:01 from IEEE Xplore. Restrictions apply. 2.1. Fu’s Cookie Protocol An attacker can register as a legitimate client with a server and then gather a large number of cookies is- Fu’s cookie protocol is shown in Figure 1. sued by the server. If the data fields of all of these cookies are encrypted by the same server key, the at- user name|expiration time|data tacker could possibly discover this key using cryptanal- |HMAC( user name|expiration time|data, sk) ysis.