Password field autocomplete

Scan.now finds every <input type="password"> on the homepage and any form it links to as a login or sign-up page, and reads the autocomplete attribute on the field and its form. It reports three states as information: the attribute is absent (acceptable, browsers apply heuristics); it is set to off (noted, because Chrome, Firefox, Safari and Edge all ignore off on login fields and it merely interferes with password managers); or it uses the standard tokens current-password or new-password (best practice). It also checks whether the accompanying username or email field is marked autocomplete="username", and flags any onpaste handler or readonly trick intended to block pasting. This check is informational: it concerns usability and phishing resistance rather than a server-side weakness.

Password managers are one of the most effective defences ordinary users have. They generate long unique passwords, they only offer to fill on the origin where a credential was saved, so a lookalike domain gets nothing, and they remove the temptation to reuse. Anything that fights the manager pushes users toward weaker, reused, retyped passwords. autocomplete="off" on a login form has been ignored by all major browsers for years precisely because the "security" it promised was illusory and the cost was real. Getting the tokens right does more than avoid harm: new-password tells the browser to offer a generated password on registration and change-password forms and not to fill the old one there, and username lets the manager save the pair correctly. NIST SP 800-63B advises that verifiers should permit paste, for the same reason. The password managers guide and password security guide give the user-side view.

Login form:

<form method="post" action="/login">
  <input type="email" name="email" autocomplete="username" required>
  <input type="password" name="password" autocomplete="current-password" required>
  <button>Sign in</button>
</form>

Registration or change-password form:

<input type="email" name="email" autocomplete="username">
<input type="password" name="new_password" autocomplete="new-password">
<input type="password" name="confirm" autocomplete="new-password">

Django forms, setting the attribute on the widget:

password = forms.CharField(
    widget=forms.PasswordInput(attrs={"autocomplete": "current-password"}))

Remove any onpaste="return false" or JavaScript that clears pasted values. Keep the username field visible on the same page as the password field, even in a two-step flow (a hidden autocomplete="username" input on step two is fine), so the manager can associate them. If a compliance requirement seems to demand disabling autocomplete, read it again: it almost always targets card data or one-time codes, which take autocomplete="cc-number" and one-time-code respectively, not passwords.