I'm evaluating a one-time-secret service for use in a highly regulated environment. The tools I've reviewed appear to avoid storing the actual secret in their databases and instead keep an audit trail showing which IP created or accessed a secret and what type of content was involved. Is that generally sufficient for compliance, or are there situations where the original secret must be retained? I'm also wondering what other systems might accidentally record it, such as web server access logs, proxies, or monitoring tools.
3 Answers
Remember that the application database is only one possible copy. If the secret or its token appears in a URL path or query string, web servers, reverse proxies, load balancers, browser history, analytics systems, and monitoring tools may record it in plain text. Check access-log retention and redaction at every layer, and avoid placing sensitive values in URLs when possible. Use a request body or another mechanism that your infrastructure is configured not to log, then verify the behavior rather than assuming it.
In most cases, retaining the secret itself is not necessary and is arguably the safer design. A useful audit trail can record who created or accessed a secret, when it happened, whether access succeeded, the source IP or identity, and which resource was involved. Keeping the actual value undermines the purpose of a one-time secret and creates another place attackers could obtain it. Compliance requirements vary, so the final decision should be based on your organization’s policies and applicable regulations, but the general principle is to minimize sensitive data retention.
I would avoid putting secrets in audit logs entirely. The audit record should prove that an action happened without making it possible to reconstruct the secret or repeat the action.
If you need to correlate events, store a non-reversible identifier rather than the secret. Depending on the design, that could be a record ID, a keyed hash, a resource identifier, or a fingerprint of a public key. Log creation, attempted access, successful or failed redemption, expiration, and deletion without recording the secret itself. That gives investigators useful evidence while limiting the damage if logs or backups are exposed.
Exactly. A system can avoid storing the value in its database while still leaking it through ordinary HTTP access logs. Sensitive values should not be sent in URLs, and existing logs should have appropriate retention and filtering.