Secrets Generation Checklist: API Keys, Passwords, and JWT Secrets
A step-by-step checklist for generating and managing secrets safely in modern applications.
Why secret quality matters
A weak or predictably generated secret is as dangerous as no secret at all. Short passwords are brute-forced in seconds. API keys with low entropy can be guessed. JWT secrets shorter than 256 bits may be cracked offline from a captured token. Generating secrets correctly is the first line of defense.
Checklist: generating a secret
Use a cryptographically secure random source
Never use Math.random(), timestamp-based seeds, or predictable sequences. Use crypto.getRandomValues() in browsers, crypto.randomBytes() in Node.js, secrets.token_bytes() in Python, or a generator like the one on this site that uses the browser's built-in CSPRNG.
Choose sufficient length
For passwords: minimum 16 characters from a full character set. For API keys: 32+ random bytes (encoded as 64 hex characters or ~43 Base64 characters). For JWT HS256 secrets: minimum 32 bytes (256 bits). For HS512: minimum 64 bytes.
Use a character set that fits the context
Human-typed passwords benefit from mixed case, digits, and symbols. Machine-generated API keys are best as hex or Base64url to avoid special characters that cause issues in URLs, shell scripts, and config files. Avoid ambiguous characters (0/O, l/1) in secrets that humans may need to type.
Never log secrets
Secrets must never appear in application logs, error messages, stack traces, or crash reports. Audit your logging configuration and redact or mask secret fields before shipping to log aggregators.
Store secrets in a secrets manager or environment variables
Hard-coded secrets in source code are a critical vulnerability. Use environment variables for local development and a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password Secrets Automation) for production. Never commit .env files to source control.
Rotate secrets on a schedule
Rotate API keys and long-lived tokens periodically (every 90 days is a common baseline). Rotate immediately if a secret is suspected to be compromised. Design systems to support rotation without downtime by accepting both old and new secrets during a transition window.
Scope secrets to the minimum necessary permissions
An API key should only have access to the resources it needs. A read-only key cannot write data if it is compromised. Apply least-privilege to all secrets and service accounts.
Encoding secrets safely
When a secret needs to travel through a text channel — an environment variable, a config file, an HTTP header — encoding it safely matters. Base64 is commonly used to encode binary secrets as a single-line string (useful for PEM keys in env vars). URL encoding handles secrets embedded in query strings or OAuth redirect URIs. Never embed raw secrets directly in URLs without encoding first.
What teams usually miss after generation
Generating a strong secret is only the opening move. Many leaks happen later: secrets are pasted into chat, copied into tickets, committed to sample config files, or left in CI logs when debugging deployment issues. A checklist is only useful if it includes the full lifecycle from creation to rotation to retirement.
That is why mature teams treat secrets as operational assets, not one-time strings. Access rules, audit trails, environment separation, and revocation plans matter almost as much as entropy.
A practical deployment checklist
- Generate in the right environment so production secrets are not created on a random developer laptop unless policy allows it.
- Name secrets consistently so teams can tell staging from production and rotate the right material under pressure.
- Load them through one trusted path such as a secrets manager, sealed env injection, or platform-native secret store.
- Verify applications fail safely if a secret is missing, malformed, or revoked.
- Document rotation ownership so someone specific is responsible when a credential must change quickly.
Decision rule
If a credential protects real access, assume the job is bigger than random-string generation. You need enough entropy, the right storage path, a rotation plan, and controls that keep the secret out of logs and source control.
Strong secrets fail in practice when the surrounding process is weak. The checklist works best when security and operations own it together.