SafeKeeper: Protecting Web Passwords using Trusted Execution Environments Klaudia Krawiecka Arseny Kurnikov Andrew Paverd Aalto University, Finland Aalto University, Finland Aalto University, Finland [email protected] [email protected] [email protected] Mohammad Mannan N. Asokan Concordia University, Canada Aalto University, Finland [email protected] [email protected] ABSTRACT Phishing attacks are prevalent in the wild, affecting home and Passwords are undoubtedly the most dominant user authentication business users alike (cf. APWG [2], PhishTank [35]), and increas- mechanism on the web today. Although they are inexpensive and ingly using TLS certificates from browser-trusted CAs (see e.g. [33]). easy-to-use, security concerns of password-based authentication While advanced anti-phishing solutions exist [13, 31], and will im- are serious. Phishing and theft of password databases are two crit- prove over time, they alone cannot address the password confi- ical concerns. The tendency of users to re-use passwords across dentiality problem adequately, because users may unknowingly different services exacerbates the impact of these two concerns. or inadvertently disclose passwords to malicious servers, which Current solutions addressing these concerns are not fully satisfac- can then use the collected passwords at other servers. Note that tory: they typically address only one of the two concerns; they an estimated 43–51% of users reuse passwords across different ser- do not protect passwords from rogue servers; they do not provide vices [15] (see also more recent reuse analyses [23, 25, 44]). any verifiable evidence of their (server-side) adoption to users; and Password database breaches are increasingly frequent: hundreds they face deployability challenges in terms of the cost for service of millions of passwords have been leaked in recent years (see providers and/or ease-of-use for end users. e.g. [17, 36]). Users are completely powerless against such breaches. We present SafeKeeper, a comprehensive approach to protect the Password breaches are commonly dealt with by asking users to confidentiality of passwords in web authentication systems. Unlike quickly reset their passwords, which is not very effective [24]. Ex- previous approaches, SafeKeeper protects user passwords against pecting users to select a different strong password for every site is very strong adversaries, including rogue servers and sophisticated unrealistic [32], and thus widespread password reuse makes these external phishers. It is relatively inexpensive to deploy as it (i) uses breaches problematic beyond the sites where the actual leak oc- widely available hardware security mechanisms like Intel SGX, (ii) is curred [25]. Stolen passwords can also lead to large-scale breaches integrated into popular web platforms like WordPress, and (iii) has of privacy/security sensitive data [43]. Several recent solutions small performance overhead. We describe a variety of challenges (e.g. [5, 11, 19, 30]) have been proposed to address password data- in designing and implementing such a system, and how we over- base breaches. Some of them (e.g. [5, 11, 30]) make use of hardware- come them. Through an 86-participant user study, and systematic based trusted execution environments (TEEs) on the server side, but analysis and experiments, we demonstrate the usability, security none can protect password confidentiality against rogue servers (i.e. and deployability of SafeKeeper, which is available as open-source. compromised servers, or servers belonging to malicious operators). Designing effective solutions to protect passwords against rogue servers poses multiple technical challenges in terms of security (How to hide passwords from the authenticating server itself? How to rate-limit password testing by the server?); usability (How to 1 INTRODUCTION minimize the burden on users? How to support login from diverse arXiv:1709.01261v2 [cs.CR] 23 Apr 2018 Passwords are by far the most widely used primary authentication user devices?); user-verifiability (How to notify users when the mechanism on the web. Although many alternative schemes have solution is active?); performance (How to realize this at scale?); been proposed, none has yet challenged the dominance of pass- and deployability (How to allow easy/inexpensive integration with words. In the evaluation framework of authentication mechanisms popular website frameworks?). Bonneau et al. [10] observed: “many by Bonneau et al. [10], passwords have the best overall usability, academic proposals have failed to gain traction because researchers since they are easy to understand, efficient to use, and don’t require rarely consider a sufficiently wide range of real-world constraints”. the user to carry additional devices/tokens. They also excel in terms We present SafeKeeper, a comprehensive system for protecting of deployability, since they are compatible with virtually all servers password confidentiality in web services. Unlike all previous propos- and web browsers, incur minimal cost per user, and are accessible, als, SafeKeeper defends against both phishing and password database mature, and non-proprietary. However, in terms of security, pass- theft, even in the case of rogue servers. At its core, SafeKeeper relies words are currently a comparatively poor choice. The two most on a server-side password protection service that computes a keyed critical security concerns, leading to the compromise of a large one-way function on the passwords before they are stored in the number of passwords, include: (i) phishing of passwords from users, database. This service is protected by a server-side TEE, which and (ii) password database breaches from servers. isolates the service from all other software on the server. SafeKeeper includes a novel rate-limiting mechanism to throttle online guessing 2 PRELIMINARIES attacks at a rogue server. 2.1 Storing Passwords SafeKeeper’s client-side functionality, which is implemented as a web browser addon, enables end users to detect whether a web The current best-practice for storing passwords is for the server to server is running the SafeKeeper password protection service within compute a one-way function on the password (e.g. a cryptographic a server-side TEE, and to establish a secure channel from their hash), and store only the result in the database. When the user browsers directly to it. This mechanism assures a user that it is safe logs in, the supplied password is passed through the same one-way to enter the password as it will be accessible only to the SafeKeeper function and compared to the value in the database. Although an password protection service on the server. Unlike other client-side adversary who obtains the database cannot reverse the one-way assurance approaches that rely on reliably identifying servers (e.g. function, he can guess candidate passwords and apply the same one- by checking URLs or TLS certificates), or verifying their expected way function in order to test his guesses. Since passwords are not functionality, our approach relies only on signaling users via the strong secrets (e.g. compared to cryptographic keys), this type of SafeKeeper browser addon, and thereby allowing them to correctly brute force guessing attack is often feasible. The adversary can even identify the server-side code that will process the password. As long speed up this attack using rainbow tables – pre-computed tables of as users correctly recognize SafeKeeper’s client-side signaling, and hashed passwords. If multiple users choose the same password, the enter their passwords only to SafeKeeper-enabled web servers, confi- results of the one-way function would also be the same. dentiality of their password is guaranteed, even if users mistook the To prevent the use of rainbow tables and avoid revealing dupli- identity of the server (e.g. phishing), or the server is malicious/compro- cate passwords, it is customary to use a salt – a random number mised (rogue server). As such, SafeKeeper may present a significant unique to each user that is concatenated with the password before shift in phishing avoidance and password protection. being hashed. However, since salt values are stored in the database, Our design considers deployability as a primary objective. We an adversary who obtains this database can still mount brute-force demonstrate this by developing a fully-functional implementation password guessing attacks against specific users by concatenating of SafeKeeper using Intel’s recent Software Guard Extensions (SGX), his guesses with the corresponding salt values. and integrating this with minimal software changes into PHPass, Another layer of defence is to also use a pepper [7] – a random the password hashing framework used in popular platforms like value included in every password hash but not stored in the pass- WordPress, Joomla, and Drupal, which as of April 2018 accounted word database. The pepper is usually the same for each user e.g. for over 35% of the Alexa top 10-million websites [40]. SafeKeeper’s Dropbox uses a global pepper to protect their users’ passwords [18]. client-end functionality does not depend on any additional de- Without knowing the pepper value, the adversary cannot test pass- vice/service/hardware feature, and thus can be implemented in word guesses against a stolen database. Therefore, the challenge most user devices/OSes, including smartphones. Our implementa- is to protect the pepper from an adversary (who may compromise tion is available as open-source