This post explains how to implement IA.L2-3.5.11 — "Obscure feedback of authentication information" — for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2, with practical code and configuration examples you can apply to web apps and APIs to reduce account enumeration, credential stuffing, and other authentication reconnaissance risks.
What the control requires and why it matters
IA.L2-3.5.11 requires that systems avoid disclosing authentication-related information to unauthenticated users that could help an attacker confirm account existence, authentication factors, or reasons for failure. For Compliance Framework implementation this means designing login, password-reset, MFA, and API error responses to be indistinguishable to an attacker while still being usable for legitimate users and auditors.
Key implementation patterns for web apps and APIs
Three practical patterns satisfy the control: (1) provide generic, identical error messages for authentication failures; (2) normalize response timing so attackers can't infer status via timing attacks; and (3) avoid revealing identifiers or delivery channels during recovery flows (e.g., "If an account exists, we've sent an email"). These patterns apply in both UI-driven web apps and machine-facing APIs. In addition, instrument server-side logging for diagnostics while masking PII to create audit evidence for Compliance Framework reviews.
Web login and password-reset flows (practical steps)
On the login page show a single generic message such as "Invalid username or password" on any failure. For "forgot password" flows show "If an account exists for that email, a recovery link has been sent" and avoid including the email address or partial identifiers in the message or the HTML. Implement server-side dummy work (see code examples below) when a username/email is not found so timing for "user not found" and "bad password" are similar, and rate-limit or CAPTCHA suspicious attempts.
API endpoints: JSON responses, status codes, and timing
For APIs return a consistent JSON response body and HTTP status code for all authentication failures so callers cannot distinguish "user does not exist" from "invalid credentials." Example: use HTTP 401 with a constant response body {"success":false,"error":"Invalid credentials"} for both cases, or use HTTP 400/200 if internal policy prefers, but keep it consistent. To mitigate timing attacks, perform a dummy password hash comparison when the user is missing and add jitter or a constant processing window for all auth responses.
Practical code examples
The following minimal examples show (A) running a dummy password hash compare when a user is missing, and (B) returning a consistent API response. These examples are intentionally small; integrate them into your existing auth pipeline and logging strategy.
// Node + Express + bcrypt example (login handler)
const express = require('express');
const bcrypt = require('bcrypt');
const DUMMY_HASH = '$2b$12$......................................'; // precomputed bcrypt hash
app.post('/api/login', async (req, res) => {
const { username, password } = req.body;
const user = await db.findUserByUsername(username); // may return null
// if user exists, compare with their hash; otherwise compare against dummy hash
const hashToCheck = user ? user.passwordHash : DUMMY_HASH;
const passwordMatches = await bcrypt.compare(password, hashToCheck);
// Always return identical response for any auth failure
if (!user || !passwordMatches) {
// optional: log failure with masked username, timestamp, IP, event id
return res.status(401).json({ success: false, error: 'Invalid username or password' });
}
// normal success path...
});
# Django example (views.py)
from django.contrib.auth.hashers import check_password
from django.contrib.auth import get_user_model
from django.http import JsonResponse
DUMMY_HASH = 'pbkdf2_sha256$260000$...'
def api_login(request):
data = json.loads(request.body)
username = data.get('username')
password = data.get('password')
try:
user = get_user_model().objects.get(username=username)
hash_to_check = user.password
except get_user_model().DoesNotExist:
user = None
hash_to_check = DUMMY_HASH
password_ok = check_password(password, hash_to_check)
if not user or not password_ok:
return JsonResponse({'success': False, 'error': 'Invalid username or password'}, status=401)
# success path...
// Spring Boot (pseudo)
String dummyHash = "$2a$10$..."; // bcrypt
User user = userRepo.findByUsername(username);
String hash = (user != null) ? user.getPasswordHash() : dummyHash;
boolean matches = bCryptPasswordEncoder.matches(password, hash);
if (user == null || !matches) {
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
writeJson(response, Map.of("success", false, "error", "Invalid username or password"));
return;
}
Supporting configuration and operational controls
Rate limiting at the gateway or web server reduces brute force and enumeration. For example, add nginx limit_req rules or use API Gateway/WAF rules to block IPs with many failed attempts. Example nginx snippet:
# nginx rate limiting
limit_req_zone $binary_remote_addr zone=auth_zone:10m rate=5r/m;
server {
location /api/login {
limit_req zone=auth_zone burst=10 nodelay;
proxy_pass http://app_servers;
}
}
Log authentication failures to a secure, access-controlled system (SIEM) including low-sensitivity metadata (timestamp, source IP, event type), but never log plaintext passwords or full PII. For Compliance Framework evidence, retain configuration files, sample logs (with masked PII), and test cases that demonstrate consistent responses and timing normalization.
Risks of not implementing IA.L2-3.5.11
If you leak authentication information through distinct messages, timing differences, or differing HTTP responses, attackers can enumerate valid accounts, focus credential-stuffing attacks, or bypass MFA via social engineering. For a small business that handles CUI this increases the chance of unauthorized access, audit findings, and potential compromise that could damage contracts and regulatory standing. Additionally, inconsistent behavior across web and API surfaces can create blind spots auditors will flag during Compliance Framework assessments.
Compliance tips and best practices
Best practices to satisfy IA.L2-3.5.11 and provide demonstrable evidence for compliance reviews include:
- Standardize auth failure messages across UI and APIs; document the exact text and where it's used.
- Implement dummy hash comparisons and/or constant-time checks to neutralize timing channels.
- Apply rate limiting, incremental backoff, and CAPTCHA where appropriate; record rule configurations.
- Centralize and protect logs; mask PII and keep an audit trail of auth failures for test evidence.
- Include automated tests (unit and integration) that assert identical responses for missing users vs bad credentials.
- Document the control mapping, implementation notes, and test results as artifact evidence for assessors.
Summary: to meet IA.L2-3.5.11, make authentication failures indistinguishable by normalizing messages, timing, and HTTP responses across web and API endpoints; use dummy hash checks, consistent JSON bodies, rate limiting, and careful logging to both protect users and produce audit evidence for the Compliance Framework. Implement these patterns, add automated tests, and retain configuration and log artifacts to demonstrate compliance during assessments.
