Obscure feedback of authentication information
📖 What This Means
This practice requires that any feedback provided during authentication processes does not reveal sensitive information that could be exploited by attackers. For example, when a user enters a password, the system should not indicate whether the username exists or how much of the password is correct. Instead, it should provide generic feedback like 'Login failed.' This helps prevent attackers from gathering useful information to refine their attacks. A real-world example is a login page that doesn't specify whether the username or password is incorrect, making it harder for attackers to guess valid credentials.
🎯 Why It Matters
Failing to obscure authentication feedback can expose sensitive information that attackers can use to brute force or guess credentials. For instance, if a system indicates that a username exists but the password is incorrect, attackers can focus on that username. This control mitigates risks like credential stuffing and brute force attacks. A notable breach example is the 2019 Capital One breach, where attackers exploited weak authentication feedback mechanisms. From the DoD/CMMC perspective, this control is critical to protect Controlled Unclassified Information (CUI) from unauthorized access.
✅ How to Implement
- 1. Configure AWS Cognito or Azure AD to return generic error messages for failed logins.
- 2. Disable detailed error messages in GCP Identity-Aware Proxy (IAP).
- 3. Use cloud-native logging tools to monitor and ensure no sensitive information is exposed.
- 4. Implement AWS CloudWatch or Azure Monitor alerts for any detailed authentication feedback.
- 5. Regularly audit cloud configurations to ensure compliance with this practice.
📋 Evidence Examples
Authentication error message configuration
Authentication logs
Policy document
Training records
Audit report
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For IA.L2-3.5.11 ("Obscure feedback of authentication information"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"IA.L2-3.5.11 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to obscure feedback of authentication information. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"IA.L2-3.5.11 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to obscure feedback of authentication information. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"IA.L2-3.5.11 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all authentication entry points (local login, VPN, cloud, API)
- • Document the identity provider(s) and authentication flow
- • Specify MFA methods and coverage
- • Ensure this control covers all systems within your defined CUI boundary where obscure feedback of authentication information applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Identification and Authentication Policy
- 📄 Password policy configuration
- 📄 MFA enrollment records
- 📄 Service account registry
- 📄 Evidence artifacts specific to IA.L2-3.5.11
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Does your system return generic error messages for failed logins?
Question 2: Are authentication logs monitored for detailed error messages?
Question 3: Is there a documented policy for obscuring authentication feedback?
Question 4: Are employees trained on obscuring authentication feedback?
Question 5: Have you conducted an audit to verify compliance?
⚠️ Common Mistakes (What Auditors Flag)
1. Detailed error messages in login pages
2. Inconsistent practices across environments
3. Missing policy documentation
4. Inadequate training
5. Infrequent audits
📚 Parent Policy
This practice is governed by the Identification and Authentication Policy