Store API Key Verifiers Safely

An API that only checks a customer's key does not need to recover the original value. Storing plaintext keys makes a database read much more damaging. A key verifier design stores a safe identifier for lookup and a one-way value for comparison, while showing the secret to the owner only at creation.

Choose a high-entropy random key generated by a cryptographic source. Give it a non-secret prefix or ID for support and lookup. Store a keyed hash or another reviewed verifier design appropriate to the key's entropy and threat model. OWASP's secrets guidance supports limiting exposure and controlling storage; do not copy password-storage parameters blindly without considering API key format and online rate limits.

Storage record

Never log the full key at creation or verification. In the request path, parse the ID, fetch the candidate record, compare the verifier safely, then check expiry, revocation, scope, and resource ownership. Rate-limit failures without revealing whether a particular ID exists.

Creation and denial tests

In an owned environment, create a key and show it once through the approved channel. Confirm the database stores no recoverable value. Use it for an allowed request, then change one character and require denial. Revoke it and require denial again while a newly issued replacement still works. Check that a key for tenant A cannot read tenant B's record.

Record test results with key IDs only. If an existing system stores recoverable values because another workflow needs them, inventory that dependency before migration. A verifier-only design cannot support a feature that displays the old key again; replace that behavior with reissue and rotation.