Skip to main content

Busting Password Managers: Detecting AutoComplete

November 19, 2014

This is a continuation of our series on Busting Password Managers. Check out the first post here. In this post, instead of focusing on technical controls that attempt to prevent browsers from remembering sensitive passwords, we are going to focus on detecting the presence of a password manager.

Hypothesis:

Using "onkeypress" event wiring in JavaScript can detect manual password entry.

The Technique:

To test this hypothesis, we again started with the default Visual Studio 2013 MVC C# project. The source code is available at https://github.com/pvwowkfn/AutoCompleteBlog/tree/DetectPassManager.

This password manager detection technique employs JavaScript and JQuery to determine if the keyboard was used to enter the password. If the user did not manually enter text into the password input field, the detection script can show a warning message and send an indicator to the server. In our tests, this key stroke detection method works well in all of the built-in password managers for the common browsers, since they will automatically place the password into the password input field without firing "onkeypress" and “onkeydown” events.

For the detection script to work, an "onkeypress" and “onkeydown” event needs to be added to the password input field. For example:

Detecting Auto Complete 1

This event handler calls the “updateWrotePass()” function, which tests whether the password has changed. If the password has changed, the wrotepass flag is set to "true":

Detecting Auto Complete 2

When the page is loaded by the browser, our "submit()" function intercepts the regular form submit and checks the wrotepass flag. If wrotepass is set to true, then the function sets the correct form action, adds a flag (usedPassManager=false) indicating that the user wrote the password, and then submits the page to the server. However, if wrotepass is false, a warning alert is shown, and a hidden flag (warningShown=true) is added to the form to be sent to the server.

There are some peculiarities to this function. First, this authentication form will only work if JavaScript is enabled (which in 2014 is not that much of an issue). Without JavaScript, the form will submit directly to the hardcoded form action and not to the dynamic action. This can be used to allow the authentication form to only work when JavaScript is enabled. Second, adding a dynamic JQuery event handler on the form submit event may prevent Chrome 36 and IE 11 from prompting to add a password. (Firefox 30 still prompts to store the password). This may be a security feature or something overlooked by browser developers. Obviously, this behavior may change in the future.

Ultimately, this is a detective approach to solving this problem. Previous approaches were corrective in nature. Using this detection mechanism, it is possible for the developer to do a number of things besides showing a simple alert box, e.g. force the user to reset their password or maybe use two-factor authentication. If the goal is simply to detect the presence of a password manager, then the detection script could be packed or obfuscated, and the additional hidden form value could have its intent obscured by changing its name.

For extra sneakiness, JavaScript code could be added to send an XmlHttpRequest when manual password entry is detected, and the server could correlate the asynchronous message with the user. While not perfect, this sneakiness could provide useful insight to application administrators, if for no other reason than to acquire metrics that justify the expense of deploying a multi-factor, one-time password authentication solution. Or, perhaps, the application could force more frequent password changes on users who are not manually entering passwords.

Successfully works on:

Firefox: Yes

Chrome: Yes

Internet Explorer: Yes

Safari: Yes

Mobile: Yes

 

Previous Articles

Related Blogs

September 23, 2014

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" at...

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

November 13, 2014

Busting Password Managers: Encrypting Passwords on the Client

Hypothesis: If passwords are encrypted (e.g. AES) on the client in JavaScript, then browsers will not save passwords. The Technique: Normally, it is i...

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

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

July 21, 2015

Application Security Solutions

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

See Details

May 09, 2018

Application Security

Learn how Optiv can help protect your most critical enterprise applications from both internal and external threats.

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.