Password fields are autofilled

This finding appears in virtually every report and is misunderstood almost as often. The advice to disable autofill on password fields dates from a time without password managers, and applying it wholesale now makes your security weaker rather than stronger. The nuance sits in the kind of field, not in the feature.

What does the autocomplete attribute do?

Browsers can remember entered data and fill it in again later. For passwords that happens through the built-in password manager or an external one. With the autocomplete attribute on an input field you state what the browser may do with that field.

The classic advice was: disable it on password fields, because a stored password can be used by someone else. That advice has been dropped, and for a good reason. Whoever makes password managers harder to use gets users who have to remember their passwords themselves, and those choose short, predictable or reused ones. The gain on one risk does not outweigh the worsening of the other.

It is a key box you forbid because someone might break it open, after which everyone puts their key under the mat. The original risk is gone and the new one is larger.

What is right then?

Vulnerable:

<!-- Administrator sets a password for another user -->
<form action="/admin/user/password" method="post">
  <input name="user" value="j.walker@company.com">
  <input name="password" type="password">
  <button>Set</button>
</form>

This is the case where autofill is genuinely problematic. The administrator’s browser sees a password field and offers to fill in the administrator’s own stored password. If that goes unnoticed, the user is assigned the administrator’s password, with all that entails. The manager may also store it under the wrong name, causing entries to get mixed up.

Safe:

<!-- Logging in: autofill is precisely what you want -->
<form action="/login" method="post">
  <input name="email" type="email" autocomplete="username">
  <input name="password" type="password" autocomplete="current-password">
  <button>Log in</button>
</form>

<!-- Choosing a new password: the manager proposes a strong one -->
<form action="/account/password" method="post">
  <input name="current" type="password" autocomplete="current-password">
  <input name="new" type="password" autocomplete="new-password">
  <button>Change</button>
</form>

<!-- A password for someone else: autofill does not belong here -->
<form action="/admin/user/password" method="post">
  <input name="password" type="password" autocomplete="off">
  <button>Set</button>
</form>

The difference lies in the purpose of the field. On the login form autofill helps, and the explicit values make managers recognise the fields correctly. When choosing a new password, new-password signals the manager to propose a strong one rather than filling in the old. And on a field concerning someone else’s password, autofill does not belong.

What is the impact of autofilled password fields?

The severity is low, and that is justified in virtually every case. A specific situation is required: someone else must have physical or remote access to the device and the user’s profile. Whoever has that generally has more serious options already.

The situation where it does mean something is the shared workstation. At a service desk, in a production environment or in a communal space, where several people use the same profile, a stored password can be used by the next person. That is more a problem of shared profiles than of the form, though.

The reverse side weighs heavier in practice. An application making password manager use harder, by blocking autofill, preventing pasting or enforcing a low maximum length, demonstrably gets weaker passwords. That effect touches every user, every day, and not only those sharing a device.

How do you detect autofilled password fields?

A tester examines the password fields in the application and looks at the attributes: is there an explicit autocomplete value, and does it match the purpose of the field? If it is missing on the login form, that is a missed opportunity rather than a risk.

Attention goes mainly to the fields where it does matter: admin screens where a password is set for someone else, forms on shared devices, and fields where a secret is entered that is not the user’s own password, an API key, a PIN, a two-factor code. Beyond that they check whether the application actively works against password managers, for instance by blocking pasting or by building fields so a manager does not recognise them. AssistSec assesses this finding in that context, because disabling autofill wholesale is now a point of attention rather than a recommendation.

How do you prevent autofilled password fields?

• Leave autofill enabled on login forms and use autocomplete="current-password".
• Mark the username field with autocomplete="username", so managers pair the fields correctly.
• Use autocomplete="new-password" on fields where a new password is chosen.
• Set autocomplete="off" on fields where a password is set for another user.
• Allow pasting and use a generous maximum length, so password managers stay usable.
• Avoid shared profiles on communal workstations; that solves the underlying problem.
• Set a short session timeout and automatic screen locking on shared devices.
• Treat this as a point of attention in the design of your forms, not as a security measure in itself.