Dos and Don'ts of Client Authentication on the Web
Total Page:16
File Type:pdf, Size:1020Kb
Dos and Don'ts of Client Authentication on the Web Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster fubob, sit, kendras, feamster ¡ @mit.edu MIT Laboratory for Computer Science http://cookies.lcs.mit.edu/ Abstract Of the twenty-seven sites we investigated, we weakened the client authentication of two systems, gained unautho- Client authentication has been a continuous source of rized access on eight, and extracted the secret key used problems on the Web. Although many well-studied tech- to mint authenticators from one. niques exist for authentication, Web sites continue to use extremely weak authentication schemes, especially in This is perhaps surprising given the existing client non-enterprise environments such as store fronts. These authentication mechanisms within HTTP [16] and weaknesses often result from careless use of authentica- SSL/TLS [11], two well-studied mechanisms for provid- tors within Web cookies. Of the twenty-seven sites we ing authentication secure against a range of adversaries. investigated, we weakened the client authentication on However, there are many reasons that these mechanisms two systems, gained unauthorized access on eight, and are not suitable for use on the Web at large. Lack of extracted the secret key used to mint authenticators from a central infrastructure such as a public-key infrastruc- one. ture or a uniform Kerberos [40] contributes to the pro- liferation of weak schemes. We also found that many We provide a description of the limitations, require- Web sites would design their own authentication mecha- ments, and security models specific to Web client authen- nism to provide a better user experience. Unfortunately, tication. This includes the introduction of the interrog- designers and implementers often do not have a back- ative adversary, a surprisingly powerful adversary that ground in security and, as a result, do not have a good can adaptively query a Web site. understanding of the tools at their disposal. Because of this lack of control over user interfaces and unavailability We propose a set of hints for designing a secure client of a client authentication infrastructure, Web sites con- authentication scheme. Using these hints, we present the tinue to reinvent weak home-brew client authentication design and analysis of a simple authentication scheme schemes. secure against forgeries by the interrogative adversary. In conjunction with SSL, our scheme is secure against Our goal is to provide designers and implementers forgeries by the active adversary. 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 par- 1 Introduction ticularly vulnerable to adaptive chosen message attacks. We call an adversary capable of performing these attacks Client authentication is a common requirement for an interrogative adversary. It turns out that for most sys- modern Web sites as more and more personalized and tems, every user is potentially an interrogative adversary. access-controlled services move online. Unfortunately, Despite having no special access to the network (in com- many sites use authentication schemes that are extremely parison to the eavesdropping and active adversary), an in- weak and vulnerable to attack. These problems are most terrogative adversary is able to significantly compromise often due to careless use of authenticators stored on the systems by adaptively querying a Web server. We believe client. We observed this in an informal survey of authen- that, at a minimum, Web client authentication systems tication mechanisms used by various popular Web sites. should defend against this adversary. However, with this minimum security, sites may continue to be vulnerable to MIT Technical Report 818. This research was supported by a USENIX scholars fellowship. A shorter version of this document was originally attacks such as eavesdropping, server impersonation, and published in the Proceedings of the 10th USENIX Security Sympo- stream tampering. Currently, the best defense against sium, Washington, D.C., August, 2001. such attacks is to use SSL with some form of client au- thentication; see Rescorla [36] for more information on 1 the security and proper uses of SSL. The client generally speaks to the server using the Hy- pertext Transfer Protocol (HTTP [14]). This may be spo- In Section 2, we describe the limitations, require- ken over any transport mechanism but is typically either ments, and security models to consider in designing Web TCP or SSL. Since HTTP is a stateless, sessionless pro- client authentication. Using these descriptions, we cod- tocol, the client must provide an authentication token or ify the principles underlying the strengths and weak- authenticator with each request. nesses of existing systems as a set of hints in Section 3. As an example, we design a simple and flexible authenti- Computation allows the browser to transform inputs cation scheme in Section 4. We implemented this scheme before sending them to the server. This computation may and analyzed its security and performance; we present be in a strictly defined manner, such as in HTTP Digest these findings in Sections 5 and 6. Section 7 compares authentication [16] and SSL, or it may be much more the work in this paper to prior and related work. We con- flexible. Flexible computation is available via Javascript, clude with a summary of our results in Section 8. The Java, Tcl, ActiveX, Flash, and Shockwave. Depending appendix describes several existing client authentications on the application, these technologies could perhaps as- schemes in detail. sist in the authentication process. However, most of these technologies have high startup overhead and mediocre 2 Security models and definitions performance. As a result, users may choose to disable these technologies. Also, these extensions may not be Clients want to ensure that only authorized people can available on all operating systems and architectures. Any access and modify personal information that they share standard authentication scheme should be as portable and with Web sites. Similarly, Web sites want to ensure that lightweight as possible, and therefore require few or no only authorized users have access to the services and browser extensions. Thus for today’s use, any authenti- content it provides. Client authentication addresses the cation scheme should avoid using client computation for needs of both parties. deployability reasons. If absolutely necessary, Javascript and Java are commonly supported. Client authentication involves proving the identity of a client (or user) to a server on the Web. We will use Client state allows the client’s browser to store and the term “authentication” to refer to this problem. Server reuse authenticators. However, storage space may be authentication, the task of authenticating the server to the very limited. In the most limited case, the browser client, is also important but is not the focus this paper. can only store passwords associated with realms (as in HTTP Basic authentication [16]). A more flexible form In this section, we present an overview of the security of storage which is commonly available in browsers is models and definitions relevant in client authentication. the cookie [24, 31]. Cookies allow a server store a value We begin by describing the practical limitations of a Web on a client. In subsequent HTTP requests, the client authentication system. This is followed by a discussion automatically includes the cookie value. A number of of common requirements. We then characterize types of attributes can control how long cookies are kept and to breaks and adversaries. which servers they are sent. In particular, the server may request that the client discard the cookie immediately 2.1 Practical limitations or keep it until a specified time. The server may also Web authentication is primarily a practical problem of request that the client only return the cookie to certain deployability, user acceptability, and performance. hosts, domains, ports, URLs, or only over secure trans- ports. Cookies are the most widely deployed mechanism Deployability for maintaining client state. Web authentication protocols differ from traditional User acceptability authentication protocols in part because of the limited in- terface offered by the Web. The goal is to develop an au- Web sites must also consider user acceptability. Be- thentication system by using the protocols and technolo- cause sites want to attract many users, the client authenti- gies commonly available in today’s Web browsers and cation must be as non-confrontational as possible. Users servers. Authentication schemes for the Internet at large will be discouraged by schemes requiring work such as cannot rely on technology not widely deployed. For ex- installing a plug-in or clicking away dialog boxes. ample, Internet kiosks today do not have smart card read- Performance ers. Similarly, home consumers currently have little in- centive to purchase smart card readers or other hardware Stronger security protocols generally cost more in per- token systems. formance. Service providers naturally want to respond 2 to as many requests as possible. Cryptographic solutions authentication is further blurred by the practice of current will usually degrade server performance. Authentication browsers of displaying a single padlock whose meaning should not needlessly consume valuable server resources is ambiguous. such as memory and clock cycles. With current