Abstract
Subtle and sometimes baffling variations in the implementation of password-based authentication are widespread on the web. Despite being imperceptible to end users, such variations often require that password managers implement complex heuristics in order to act on the user’s behalf. These heuristics are inherently brittle. As a result, password managers are unnecessarily complex and yet they still occasionally fail to work properly on some websites. In this paper we propose PMF, a specification of simple semantic labels for password-related web forms. These semantic labels allow a software agent such as a password manager to extract meaning, such as which site the login form is for and what field in the form corresponds to the username. Our spec also allows the agent to generate a strong password on the user’s behalf. PMF reduces a password manager’s dependency on complex heuristics, making its operation more effective and dependable and bringing usability and security advantages to users and website operators.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Similar content being viewed by others
Notes
- 1.
See password_manager.cc in the Chromium source code (https://code.google.com/p/chromium/codesearch#chromium/src/components/password_manager/core/browser/password_manager.cc), accessed July 2015.
- 2.
Users of password managers are still exposed to malware; we are not claiming that the security offered by password managers is absolute (see Sect. 5). Besides, our proposal implicitly also supports higher-security password managers running on dedicated hardware.
- 3.
The latest version (as well as a complete revision history) of the PMF specification can be found at https://github.com/pmfriendly/pmf-specification.
- 4.
In these examples, grey highlights indicate PMF-related additions.
- 5.
The values of these hidden inputs are usually populated by the web server when it generates the HTML of the page and then not changed on the client side. For example, web frameworks, such as Django [6], use them to implement Cross Site Request Forgery protection.
- 6.
Often just an indication that the back-end is not even hashing the passwords, as observed by Bonneau and Preibusch [8].
- 7.
Within reasonable limits, though, to avoid denial of service—allowing passwords of several megabytes brings no security benefit and does more harm than good. To paraphrase an ancient Unix quip, “passwords in PMF may be infinite in length, where infinity is set to 256 characters”..
- 8.
This is not to say that humans could never use passwords or passphrases of that length, or that passwords of that length are necessarily always unguessable. What we mean instead is that, once we agree that a competent and non-malicious agent is generating strong random passwords on behalf and in the interest of the user, once we reach t characters then further checks are not necessary. Checking that the t characters aren’t “easy” (e.g. all the same) goes against the hypothesis that it’s in the agent’s interest to generate them at random. And if the agent is compromised then all bets are off, as it could also generate a random-looking password that the attacker could recover. So, additional checks beyond that of the length are not useful.
- 9.
See footnote 7.
- 10.
In our latest PMF specification, besides always requiring the semantic markup described in the other sections, we define full PMF compliance as requiring that the policy accept passwords of length over t regardless of their composition but we still grant partial compliance to websites that don’t implement this exception. Partially PMF compliant sites still allow reliable automated interaction for login, even though they don’t guarantee that the software agent will be able to define a compliant strong password.
- 11.
Of course a human could generate a 100-character password, but they’d have little incentive to do so knowing that they’d have to retype it every time. And, in making the heuristic fail, they’d only damage themselves. What we mean is that no human will generate a 100-character password unless they explicitly and masochistically set out to fool the heuristic—in which case they get what they deserve.
- 12.
The travelling user would not want to sync their passwords to the browser in the cybercafé. Instead of transcribing a random password to the cybercafé’s browser (which would still be exposing that account), they should use the PMF-enabled browser in their smartphone. This end-to-end solution using a trusted terminal would be more usable and more secure than either of the alternatives involving the cybercafé’s browser, and would not require any transcribing.
- 13.
Note how our new requirement of adding the “if length \(>t\)” statement to the policy may at some level represent a more significant change to the website but in practice involves much less work than our old requirement of accurately expressing the existing password composition policy in machine-readable form.
- 14.
As an example, 1Password alone is estimated to have a install base of 2 to 3 million users.
- 15.
Auto-filling of forms by the password manager improves usability and therefore, before mitigating this vulnerability by disabling the auto-filling, careful consideration is needed of the inherent trade off between security and usability. We shouldn’t lose sight of the fact that normal users don’t have threat models; therefore, simply asking them whether they want to enable or disable auto-filling is a bit of a cop out.
- 16.
A bookmarklet is a bookmark containing JavaScript that can be used to extend a web browser’s capabilities. Bookmarklets have advantages over alternatives such as addons or extensions as they are cross browser and are managed by the user like bookmarks.
References
Pinterest. https://pinterest.com. Accessed 07 November 2014
OWASP: Cross-site request forgery (csrf) prevention cheat sheet, August 2014. Accessed 06 November 2014. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., O’Connor, E., Pfeiffer, S., Hickson, I.: HTML 5.1. Working draft, W3C (2014)
Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., O’Connor, E., Pfeiffer, S.: HTML5. Recommendation, W3C, October 2014
Stuven, Sybrel (W3C): Use class with semantics in mind. http://www.w3.org/QA/Tips/goodclassnames. Accessed 07 November 2014
Django documentation: Cross Site Request Forgery protection. https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/. Accessed 07 November 2014
Bonneau, J., Xu, R.: Of contraseñas, sysmawt, and mìmǎ: Character encoding issues for web passwords. In: Web 2.0 Security & Privacy, May 2012
Bonneau, J., Preibusch, S.: The password thicket: technical and market failures in human authentication on the web. In: WEIS 2010 (2010)
Stanford University. https://itservices.stanford.edu/service/accounts/passwords/quickguide. Accessed 07 November 2014
Florencio, D., Herley, C.: A large-scale study of web password habits. In: Proceedings of the 16th International Conference on World Wide Web. WWW 2007, pp. 657–666. ACM, New York (2007)
Schneier, B.: Password safe. https://www.schneier.com/passsafe.html. Accessed 06 November 2014
Gasti, P., Rasmussen, K.B.: On the security of password manager database formats. In: Foresti, S., Yung, M., Martinelli, F. (eds.) ESORICS 2012. LNCS, vol. 7459, pp. 770–787. Springer, Heidelberg (2012)
Silver, D., Jana, S., Boneh, D., Chen, E., Jackson, C.: Password managers: attacks and defenses. In: Proceedings of 23rd USENIX Security Symposium (USENIX Security 14), pp. 449–464. USENIX Association, San Diego, August 2014
Li, Z., He, W., Akhawe, D., Song, D.: The emperor’s new password manager: security analysis of web-based password managers. In: Proceedings of 23rd USENIX Security Symposium (USENIX Security 14), pp. 465–479. USENIX Association, San Diego, August 2014
Adida, B., Barth, A., Jackson, C.: Rootkits for javascript environments. In: Proceedings of the 3rd USENIX Conference on Offensive Technologies. WOOT 2009, p. 4. USENIX Association, Berkeley (2009)
West, M.: Credential Management Level 1. Working draft, W3C (2015)
Stajano, F.: Pico: no more passwords!. In: Christianson, B., Crispo, B., Malcolm, J., Stajano, F. (eds.) Security Protocols 2011. LNCS, vol. 7114, pp. 49–81. Springer, Heidelberg (2011)
Stajano, F., Jenkinson, G., Payne, J., Spencer, M., Stafford-Fraser, Q., Warrington, C.: Bootstrapping adoption of the pico password replacement system. In: Christianson, B., Malcolm, J., Matyáš, V., Švenda, P., Stajano, F., Anderson, J. (eds.) Security Protocols 2014. LNCS, vol. 8809, pp. 172–186. Springer, Heidelberg (2014)
Acknowledgements
We gratefully acknowledge the European Research Council for funding this research under grant 307224 (Pico).
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2015 Springer International Publishing Switzerland
About this paper
Cite this paper
Stajano, F., Spencer, M., Jenkinson, G., Stafford-Fraser, Q. (2015). Password-Manager Friendly (PMF): Semantic Annotations to Improve the Effectiveness of Password Managers. In: Mjølsnes, S. (eds) Technology and Practice of Passwords. PASSWORDS 2014. Lecture Notes in Computer Science(), vol 9393. Springer, Cham. https://doi.org/10.1007/978-3-319-24192-0_4
Download citation
DOI: https://doi.org/10.1007/978-3-319-24192-0_4
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-24191-3
Online ISBN: 978-3-319-24192-0
eBook Packages: Computer ScienceComputer Science (R0)