Stronger Password Authentication Using Browser Extensions∗ Blake Ross Collin Jackson Nick Miyake [email protected] [email protected] [email protected] Dan Boneh John C Mitchell [email protected] [email protected] Abstract hackers to break into a low security site that simply stores username/passwords in the clear and use the We describe a browser extension, PwdHash, retrieved passwords at a high security site, such as that transparently produces a different password for a bank. This attack, which requires little work, can each site, improving web password security and de- lead to the theft of thousands of banking passwords. fending against password phishing and other attacks. While password authentication could be abandoned Since the browser extension applies a cryptographic in favor of hardware tokens or client certificates, both hash function to a combination of the plaintext pass- options are difficult to adopt because of the cost and word entered by the user, data associated with the inconvenience of hardware tokens and the overhead web site, and (optionally) a private salt stored on the of managing client certificates. client machine, theft of the password received at one site will not yield a password that is useful at an- In this paper, we describe the design, user in- other site. While the scheme requires no changes on terface, and implementation of a browser extension, the server side, implementing this password method PwdHash, that strengthens web password authen- securely and transparently in a web browser exten- tication. We believe that by providing customized sion turns out to be quite difficult. We describe the passwords, preferably over SSL, we can reduce the challenges we faced in implementing PwdHash and threat of password attacks with no server changes some techniques that may be useful to anyone facing and little or no change to the user experience. Since similar security issues in a browser environment. the users who fall victim to many common attacks are technically unsophisticated, our techniques are 1 Introduction designed to transparently provide novice users with the benefits of password practices that are otherwise Although techniques such as SSL/TLS with only feasible for security experts. We have experi- client-side certificates [DA99] are well known in the mented with Internet Explorer and Mozilla Firefox security research community, most commercial web implementations and report the result of initial user sites rely on a relatively weak form of password au- studies. thentication: the browser simply sends a user’s plain- text password to a remote web server, often using In essence, our password hashing method is ex- SSL. Even when used over an encrypted connection, tremely simple: rather than send the user’s cleartext this form of password authentication is vulnerable to password to a remote site, we send a hash value de- attack. In phishing scams, an attacker sets up a web rived from the user’s password, pwd, and the site do- site that masquerades as a legitimate site. By tricking main name. Specifically, PwdHash captures all user a user, the phishing site obtains the user’s cleartext input to a password field and sends hash(pwd,dom) password for the legitimate site. Phishing has proven to the remote site, where dom is derived from the do- surprisingly effective at stealing user passwords, as main name of the remote site. We refer to dom as documented in reports from the anti-phishing work- the salt. The hash is implemented using a Pseudo ing group [APW]. In common password attacks, Random Function keyed by the password, as de- hackers exploit the fact that web users often use the scribed in Section 3. Since the hash output is tailored same password at many different sites. This allows to meet server password requirements, the resulting hashed password is handled normally at the server; ∗Supported by NSF through the PORTIA project. no server modifications are required. This technique USENIX Association 14th USENIX Security Symposium 17 deters password phishing since the password received 2 Challenges at a phishing site is not useful at any other domain. We begin with a description of various chal- The cryptographic hash makes it difficult to compute lenges associated with implementing password hash- hash(pwd,dom2) from hash(pwd,dom1) for any do- ing in a web browser extension. Although our im- main dom2 distinct from dom1. For the same reason, plementations are for Internet Explorer and Mozilla passwords gathered by breaking into a low security Firefox, these difficulties may arise in any contempo- site are not useful at any other site, thus protecting rary browser. financial institutions from sites with lax security (e.g. those coordinating high school reunions). • JavaScript attacks. How do we prevent The main idea of password hashing, which is JavaScript on a phishing page from stealing the attractively simple, has been explored in previous user’s cleartext password? projects (discussed in Section 8). The focus of this paper is on the implementation of password hashing • Salting. What information do we use as as a secure and transparent extension (i.e. plug-in) to the salt when hashing passwords? For ex- modern browsers. Password hashing is a seductively ample, should we use the name of the do- simple concept in theory that is surprisingly challeng- main that will receive the form data, or should ing to implement in practice, both technically and in we use the domain that is hosting the lo- terms of the user experience. First, password hashing gin form? How do we ensure that the same alone is not a sufficient deterrent against phishing due salt is used for both www.amazon.com and to the considerable power afforded to web develop- www.amazon.co.uk? ers in modern browsers. For example, JavaScript on phishing pages could potentially intercept the user’s • Encoding. How do we encode the hashed cleartext password before it is hashed, whether it is value to comply with the site’s password re- typed in by the user or pasted from the clipboard. quirements? Some sites require passwords to Since these types of interactions will also raise prob- contain non-alphanumeric characters, while oth- lems for a range of other possible browser extension ers reject such passwords. projects, we expect the solutions we developed to be • Auto-complete. Our extension must be compat- relevant to other browser-based projects. And sec- ible with the password auto-complete database ond, simple ideas do not necessarily translate into and other browser features. simple user experiences. For example, the exten- sion must recognize which user input to hash. If a • Password reset. After the PwdHash extension user wishes to start using our extension, for exam- is installed, it must help users update their pass- ple, she will have to visit the change-password page words at websites they frequent to the hashed for her existing accounts and indicate to the exten- counterparts. sion to hash the new password she types in, but not the old. This is a new and potentially jarring step for • Roaming. Some users are not able or permitted novice users, but the extension cannot simply hash to install extensions at every computer they use. both password entries. We must nevertheless enable these users to log in. To summarize, our goals in the design and im- plementation of PwdHash are to strengthen pass- • Dictionary attacks. Phishing sites obtain a hash word authentication using a browser extension such of the user’s password that could be vulnerable that: (1) we introduce little or no change to the to a dictionary attack. How do we reduce the user experience, and (2) we require no server-side effectiveness of dictionary attacks? changes. Section 2 summarizes the main challenges we faced in building PwdHash, while sections 3 Conceptually, these problems fall into three cate- through 5 present solutions to these challenges. Sec- gories. Salting, encoding, and dictionary attacks are tion 6 discusses specifics of the Internet Explorer implementation decisions for the password hashing and Mozilla Firefox implementations and section 7 function itself; JavaScript and auto-complete are ex- briefly summarizes the results of our user studies. amples of general problems associated with execut- Some forms of password hashing have been used in ing in the browser environment; and password reset other systems; we survey the related work in Sec- and roaming are user experience issues. We discuss tion 8. solutions to these problems by category, beginning with defenses against JavaScript attacks. 18 14th USENIX Security Symposium USENIX Association We emphasize that we are only concerned with phisher obtains the user’s cleartext password. attacks on our extension that originate on malicious • Domain rewriting. phishing sites. Our extension is not designed to de- When the page is first fend against spyware and keyboard loggers running loaded, the form action attribute can point to a as other browser extensions or elsewhere on the user’s proper banking site. However, when the user machine. hits the “login” button, a JavaScript function changes the form action to point to the phish- 3 Isolation and the browser environment ing site (Figure 2). As a result, in the straight- forward implementation, the browser sends the Password hashing is computed using a Pseudo user’s password hashed with the banking do- Random Function (PRF) [GGM86] as follows: main name to the phisher. The phisher thus ob- tains the user’s banking password. hash(pwd,dom) = PRFpwd(dom) • Mock password field. Phishers can create a text where the user’s password pwd is used as the PRF key field <input type=“text”> that behaves like a and the remote site’s domain name dom or some vari- password field.