Busting Password Managers: Inert Password Input Field Injection

By Tim MalcomVetter, Paul Wowk ·

This is a continuation of our Busting Password Manager series. Learn more here.

Hypothesis: If an extra (hidden) password input field is inserted above the real password field, then browsers will not save passwords.

The Technique: Think of this technique as "inert password field injection." To test this out, we started with the canned Visual Studio 2013 ASP.NET MVC C# project. The code for this solution can be downloaded from https://github.com/pvwowkfn/AutoCompleteBlog/tree/InertPassword.

First, we modified the AccountModel.cs model file to add the extra password field string property:

And in the Login.cshtml view file, simply insert the control on the page inside a DIV with off-screen styling, but before the actual password input field:

Note no changes were made to the code in the MVC controllers, because we want the server to simply ignore this "inert" password input field altogether. The user experience of the application is essentially unchanged from a user’s perspective:

The inert password input field does not render visually with that styling, so the user will not know it is there unless the HTML source is inspected. From a performance perspective, there’s virtually no impact - just one more parameter to go in the form post. 

However, those minor changes are enough to throw off the modern password managers that no longer respect the "autocomplete=off" tag.

If Chrome, Firefox or Internet Explorer (version 11) already has a saved password, that password will be sent along, but in the first password field on the form. In this case, it will be the hidden password input field that is ignored by the server. So, yes, the saved password will get transmitted back and forth, but that won’t allow a user to automatically log in with the saved password since the server ignores that field. If the user changes a password for the app, the old one will be forever cached in the browser and sent along in the first hidden, useless field while the real one is ignored by the password manager in the second, visible field. Ideally, it would delete the old password, but we’ll still take that as a win.

If the browser does not already have a saved password, there will not be a prompt to save one after successful authentication. This may be because the browsers are looking at the first password field in the request, which is just an empty string, so there’s nothing to save. This seems to dovetail with browsers’ behavior for apps that request a user’s ID, a user’s password in a first password input field and a token-code (e.g. RSA SecurID) in a second password input field. The first password input field might be saved by the password manager, but the browsers typically do not offer to remember the second password input field (the token code field), regardless of an autocomplete value.

This same inert password field injection technique can be applied to user registration or password change forms as well. For example, in the same default MVC project, edit the RegisterModel and add the extra string property:

In the Register.cshtml view, inject the inert password field just above the actual password field, and its twin confirmation password field using hidden styling like applied to a <DIV> tag. This will result in three password fields on the register page, but the inert password field is not shown on the client nor evaluated on the server:

Likewise, this inert password injection technique can be applied to the password change interaction as well. In the MVC example, add the string property to the LocalPasswordModel:

In the corresponding view, edit the _ChangePasswordPartial.cshmtl to inject the inert password input field after the old password field but before the new password field and confirmation:

In the long run, injecting an inert password field may be a slight hack, but it does appear to at least offer some odds in the favor of the developer, while illustrating this could become a minor arms race for control of password managers in the browser. For example, suppose Chrome, Firefox or IE become more sophisticated and ignore the values in password fields with hidden or off-screen styling. Some tricks might be to inject an inert password input field with visible styling, but buried under another HTML layer (floating div or iframe) that contains the actual password input field. Or perhaps developers can trick browsers by injecting more than two inert password fields. With all the popular, modern browsers it is possible to confuse the password manager by injecting an inert and unused password field.

Successfully works on:

Yes

Yes

Yes

Yes

Yes

Previous Articles