Password keyboards usually turn off autocorrect and candidates so input is not leaked

What it is

Password, PIN, and unlock fields should pop a keyboard with autocorrect, autocomplete, and IME candidates off. Candidate bars and correction chips paint the passphrase as readable words, visible to shoulder surfers and screen shares; cloud correction can also send fragments off-device. This is a different layer from masking committed characters with dots: masking covers the field; this shuts keyboard accessories. An email keyboard putting @ on the home layer does not require candidates off; a password keyboard's first job is not to display or report the content.

Why it happens

The system chooses keyboard configuration from field semantics (password, newPassword, secureTextEntry): learning off, contacts off, gesture typing off, sometimes even the key-preview bubble. A site that uses type=text and paints its own dots still gets a normal-text keyboard, and candidates leak. IME candidates are especially dangerous: they translate pinyin into common words, which is guessing the password on screen. Autocorrect turning p@ss into a dictionary word both corrupts the password and displays the intended token.

Studying it

Type an unnatural passphrase into correctly versus incorrectly marked password fields and screenshot for candidates, correction chips, and key bubbles. Repeat with screen sharing and notification previews on. Compare a native password control with a custom dotted text box. Do not use your own frequent words as passphrase material, which can make correction “look fine.”

Where it stops holding

Password-manager fill suggestions are another channel, on the field rather than the keyboard candidate bar, and need their own visibility and consent. SMS fill of one-time codes is intended, but the candidate bar should still be off. Assistive key echo should take a private audio path, not an on-screen bubble. A game chat mis-marked as a password field will wrongly kill correction—that is bad semantics.

Applying it

• Use the platform's secure-text semantics for passwords and PINs; do not fake dots on a normal text box.
• Confirm the popped keyboard has no candidate bar, correction chips, or learning.
• Hide or blur both the field and keyboard previews during screen share.
• Verify by typing a string that looks like a word but is not: aside from dots, the screen must not show that string in readable form. Keyboard-configuration screenshots belong on the release checklist.

Related

• Same group: C6.29.1 Some systems pop a randomized number pad on password fields to block position-based shoulder surfing · C6.29.3 Randomized pads sacrifice touch-typing speed; that is a security–efficiency tradeoff · C6.29.4 Password fields should not use third-party IMEs' cloud candidate services, which can leak plaintext
• Adjacent: C6.11 Autocorrect · C6.12 IME candidates
• Search: secure text entry · disable autocorrect · password keyboard