Disabling paste in a password field silently breaks password managers
Aliases: disable paste · password field autocomplete · manager fill
What it is
To block shoulder surfing or scripts, some password fields intercept paste, disable autofill, or accept only keystrokes that “look human.” Blocking password managers means those tactics stop a manager-generated high-entropy string from entering the field, so people fall back to a short secret they can memorize. NIST SP 800-63B explicitly requires allowing paste. This entry is only about whether the input channel is open to managers. It is not about how harsh composition rules are, and not about when rules are shown.
Why it happens
A password manager’s model is: people cannot remember high-entropy strings, so software generates and fills them. Paste and OS-level autofill are the standard fill interfaces. After paste is intercepted, people copy the string out of the manager glyph by glyph, error rates rise, and they switch to a short memorable secret—the manager is bypassed and the product receives a weaker secret. Script detection that treats “even typing speed” as a bot also false-hits autofill. A confirm field that forbids paste from the first field forces a long string to sit visible on screen for comparison. Blocking paste does not stop real automated attacks (they do not use the clipboard); it specially punishes people who followed the guidance.
Studying it
On real browsers and OSes with mainstream managers installed, compare allow-paste, intercept-paste, and fields that disable autocomplete=new-password, and see whether a generated string can enter in one action.
Independent variables: paste interception, correct autocomplete semantics, whether the confirm box accepts a copy from the primary box. Dependent variables: manager fill success, switch to a typed short password, transcription errors, time to finish.
Labs that forbid managers measure only typing, and the conclusion flips. Do not treat “blocking paste reduced bot signups” as evidence it is harmless to managers—that is a separate risk control, and it belongs in bot detection, not in the password field’s input events.
Where it stops holding
On a shared screen or under shoulder surfing, someone may choose not to paste; that is a situational choice, not a field policy. Some assistive input works through the clipboard; blocking paste turns the aid off. OTP fields needing paste are a different group; password autocomplete semantics are current-password / new-password and must not be mixed with one-time-code semantics. Legacy bank soft keyboards kept for malware resistance should still offer “use the system keyboard and allow paste” as an exit, not as the only path.
Applying it
- Allow paste and system autofill on password and confirm fields; use platform-recommended autocomplete attributes; do not disable the clipboard on the field.
- Let the confirm field accept a copy from the primary field or a second manager fill; do not force on-screen checking of a long string.
- Put anti-bot on separate signals (device reputation, challenges), not on typing cadence or a paste ban.
- Verify with the OS manager and at least one third-party manager generating a long random string and filling both primary and confirm in one shot. Then copy from primary to confirm. Interception at any step fails. Sample new registrations for obviously typed short secrets; that share should fall after paste is opened.