Skip to main content

Busting Password Managers

September 23, 2014

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 …

 

Related Blogs

December 17, 2015

Bypassing CSRF Tokens via XSS

Many web development platforms provide libraries that handle the creation and validation of tokens with each HTTP request to prevent Cross Site Reques...

See Details

July 15, 2014

Application Security by Obscurity | Optiv

“Security by obscurity” is a pejorative term to most in the security industry and with good reason. Typically, it’s just a matter of time before light...

See Details

October 02, 2014

Busting Password Managers: AJAX Logins

Hypothesis: If the username and password are submitted using AJAX, then browsers will not save passwords. The Technique: Our theory is that browsers o...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.


Privacy Policy

Related Insights

July 21, 2015

Application Security Solutions

Learn how Optiv can help with web, email and application protection.

See Details

May 23, 2016

Next Generation Identity and Access Management (Next Gen IAM)

Having spent the last 17 years in the identity and access management (IAM) space, I know two things are certain: Evolution is inevitable, and change i...

See Details

November 29, 2017

Five Steps to Ensuring a Successful Identity and Access Management Solution Deployment

After endless cost-benefit meetings, business case rewrites and months of organizational readiness activities, your identity and access management (IA...

See Details

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.

Subscribe

Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.