Record authentication events without recording secrets
Create a minimal authentication event schema. Verify login, recovery, and factor-change records while excluding credentials, session values, and private request bodies.
Authentication logs should explain an account transition without becoming a second store of credentials. Define the investigation questions first: did authentication succeed, was a recovery token used, which policy denied an action, and which component made the decision? Collect fields that answer those questions.
OWASP's logging guidance identifies sensitive data to exclude, including passwords, access tokens, and session values. The schema below is a proposed minimal event record, not permission to collect every available identifier.
Specify an event schema
Use stable event names and bounded reason codes. Distinguish an unknown account from an internal processing failure in restricted operational records without exposing that distinction to an unauthenticated browser.
| Field | Purpose | Handling rule |
|---|---|---|
| Event type | Login, recovery, or factor transition | Controlled vocabulary |
| Event time | Sequence reconstruction | Record time source and timezone |
| Internal actor reference | Associate an authenticated transition | Avoid raw credentials or recovery links |
| Outcome and reason | Explain allowed or denied behavior | Bounded server-generated values |
| Correlation reference | Join relevant service events | Do not reuse a bearer credential |
| Build or component version | Locate implementation | Keep operational access restricted |
Review whether IP or device data is necessary for your stated purpose. Apply the relevant privacy and retention policy rather than assuming more collection is always better.
Test secret exclusion at every sink
Use conspicuous synthetic secret markers in a permitted test flow. Check application logs, proxy logs, exception reports, traces, and support exports. A careful event schema does not prevent a separate request logger from recording the full body.
Exercise failed parsing and unexpected exceptions as well as successful login. Confirm that user-controlled values cannot forge additional log entries through separators or control characters. Use a structured logging library rather than concatenating untrusted strings.
Make the records usable and bounded
Verify that an investigator with the approved role can follow a synthetic recovery sequence without receiving the recovery token. Restrict export access and record access to sensitive log stores. Define retention, deletion, and storage-failure behavior with the service owner.
Test that a logging outage does not leak the original request into a fallback error message. Keep monitoring for dropped events distinct from a security alert about a user. The completed artifact should include the schema, excluded fields, sink inventory, and representative redacted events. It should support a specific investigation without preserving the credentials that could repeat the action.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP Logging Cheat SheetAccessed