Guides · Security

Secrets Generation Checklist: API Keys, Passwords, and JWT Secrets

A step-by-step checklist for generating and managing secrets safely in modern applications.

Last updated: May 4, 2026

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

1.

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.

2.

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.

3.

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.

4.

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.

5.

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.

6.

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.

7.

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.