Busting Password Managers: Detecting AutoComplete

By Tim MalcomVetter, Paul Wowk ·

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:

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":

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:






Previous Articles