Busting Password Managers

By Tim MalcomVetter, Paul Wowk ·

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.
  • Dynamically Adding Password Input Fields to a Form - This fails to stop browsers since they appear to take notice of all the fields sent in the final POST request. It does not appear to matter if the fields came from the server with the page load or if JavaScript added them to the page dynamically.
  • Changing Input Field Types - We tried using JavaScript to change the input field types around with very little success among various browsers. In fact, changing a password to a regular text field appears to worsen the problem as browsers store non-password fields differently and suggest those values in various autocomplete forms. So your password could end up as the suggested value for a message text box on a social media site.

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 …