Skip to main content

Busting Password Managers: Inert Password Input Field Injection

October 10, 2014

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


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

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

Inert Password 1

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:

Inert Password 2

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:

Inert Password 3

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:

Inert Password 4

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:

Inert Password 5

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:

Inert Password 6

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:

Inert Password 7

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:

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 19, 2014

Busting Password Managers: Detecting AutoComplete

This password manager detection technique employs JavaScript and JQuery to determine if the keyboard was used to enter the password. If the user did n...

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.


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.