I'm evaluating a one-time-secret tool for use in a highly regulated environment. The tools I've reviewed don't appear to store the actual secret in their databases. Instead, they record audit information such as which IP created or accessed a secret, what kind of secret it was, and when the action occurred. Is retaining the secret itself ever required for compliance, or is a properly designed audit trail generally sufficient?
2 Answers
Don’t only check the database and application audit log. If the secret or access token appears in a URL query string or path, web servers, proxies, load balancers, analytics tools, and browser history may record it in plain text. Review access-log retention and sanitization at every layer, and avoid putting sensitive values in URLs altogether. Use a request body or another mechanism that won’t be routinely written to access logs.
If an audit system needs to distinguish between multiple secrets without exposing them, record metadata such as the resource identifier, creation and use times, the access result, and possibly a carefully selected fingerprint or keyed hash. Even then, a hash should only be used when it serves a clear audit purpose, since weak or guessable secrets may be vulnerable to offline guessing. The actual secret should generally remain unavailable after its intended use or expiration.
Exactly. A system can avoid storing the value in its database while still leaking it into months of web-server logs. Sensitive tokens should not be placed in URLs when a request body or header-based design is available.