IA-6 Authentication Feedback asks you to obscure feedback of authentication information during the process, so unauthorized people cannot exploit it. It is one of the shortest controls in the family and one of the easiest to evidence.
800-53 binds US federal systems and contractors. Other organizations can use it as a reference for login screens and command line prompts.
What it means in practice
NIST says feedback from systems should not give information that helps compromise authentication. The classic risk is shoulder surfing on large screens. On small mobile displays the threat is lower and is balanced against typing errors, so showing the last character briefly can be acceptable.
Think beyond the password field. Error messages that reveal whether a username exists, verbose stack traces on a failed login, and secrets echoed in a terminal all give an attacker something.
Evidence to collect
- Screenshots of login and recovery screens showing masked input.
- A test showing identical error text for a bad username and a bad password.
- Configuration or code review notes for CLI tools that read secrets without echo.
- Log check showing passwords are not written to application logs.
Common gaps
A reset page that says "no account with that email". API errors that return the submitted secret. Debug logging left on.
How to implement it
Mask input everywhere. Use one generic failure message. Scrub secrets from logs with a redaction filter and test it.
Quick check
Why are generic login errors part of IA-6?
Specific errors tell an attacker which part of the credential was right, which helps them compromise authentication.
