Busting Password Managers
As you may have noticed, web browser password managers have begun to take over. Until recently, a developer could simply add the "AutoComplete=off" attribute to any HTML forms or input fields, including password input fields, and browsers would kindly oblige the request not to locally store any sensitive information entered by the user.
For years, though, there were add-ons, such as GreaseMonkey scripts, that would allow a user to customize the browser to ignore the "AutoComplete=off" request. Many of the add-ons literally edited the DOM to override the "AutoComplete" attribute to the "on" value. Now, the most recent versions of Chrome, Firefox (v 30+), Internet Explorer (v11) and Safari all override the autocomplete setting for password input fields. Developers whose code asks browsers to comply with no password saving policies may be disappointed to find out all the latest browsers will save passwords anyway. The browser vendors claim this change of policy puts the user in control, and “besides, it requires permission from the user before passwords are saved.” As if people never make mistakes and browsers never have any vulnerabilities…
Fundamentally, the core issue is trusting that a client will choose to follow directions provided by the server. We must keep in mind that the server is "asking" the client not to remember the password. The server is not "telling" and certainly not "demanding" that the browser comply. Even if the server "demanded," there is no way to determine compliance with 100% certainty on the server side.
Case in point: observe all of the password-saving browser add-ons that existed before these recent changes. Anyone who has spent any time in security, let alone application security, already knows that expecting clients to always follow a server’s request is wishful thinking at best and completely futile at worst. However, there are organizations out there who are not ready to give up their "AutoComplete=off" for passwords, at least not yet, and definitely not cold turkey.
The best solution to the password-caching problem is to use multi-factor, one-time passwords. For example, RSA SecurID tokens or one-time passwords sent in SMS text messages. However, using multi-factor authentication may not be possible due to business or organizational constraints. Over the next several posts, we will analyze several tricks and techniques that may rein in the password-saving behavior without multi-factor authentication.
But first, here is a summary of things we tried that failed to stop password managers:
- Dynamically Renaming Password Fields - Turns out that browsers are smart enough to identify User ID and Password fields regardless of their name. Keeping the server and client in sync with dynamically changing field names puts a real strain on the developer.
- Encoding Passwords on the Client - We tried just shifting the encoding of the password - to base64 for example - and some of the browsers were still able to detect and save passwords.
While those didn’t work, we did have varied success with these solutions, which we will cover in detail with code examples in future posts. Stay tuned …
- Passwords Over AJAX
- Inert Password Field Injection
- Splitting User ID and Password Input Fields into Separate POSTs
- Encrypting Passwords on the Client