Secret Length Best Practices for API Keys, Passwords, and JWT Secrets
How long secrets should be in practice, why entropy matters more than decoration, and where developers choose dangerously short values.
Length is a proxy. Entropy is the real goal.
Developers often ask “how many characters should this secret be?” because length is easy to measure. But length only helps if the characters are actually random enough. A long predictable phrase is weaker than a shorter value generated from a strong random source.
In practice, good secret generation means two things together: enough length for the use case, and enough unpredictability that guessing or brute-force attacks become impractical.
Useful defaults for common cases
| Secret type | Practical baseline | Why |
|---|---|---|
| JWT HMAC secret | 64+ random characters | HS256/384/512 secrets should not be short or human-chosen. |
| API key / internal token | 32+ random characters | Enough room for strong entropy without becoming awkward to store. |
| Database or service password | 20+ random characters or strong passphrase policy | Depends on system constraints and auth model, but short passwords are rarely justified. |
Why “long enough” depends on the job
Not all secrets protect the same thing. A database password, an HMAC signing key, a webhook token, and an internal API key may all deserve different operational treatment even if they are all “just secrets” at a high level.
The more severe the impact of key exposure or key forgery, the less reason there is to settle for short convenience-oriented values.
Where teams usually go wrong
The most common problem is not “we picked 31 characters instead of 32.” It is choosing secrets that are short, memorable, environment-derived, or copied from examples in tutorials. That creates values that look secret-shaped but are much easier to attack.
Another failure mode is generating a strong secret once and then keeping it forever across every environment, backup, staging system, and teammate laptop. Generation is only one part of the lifecycle.
Short secrets usually come from workflow shortcuts
JWT secrets deserve extra caution
HMAC-signed JWTs are only as trustworthy as the secret behind them. If the secret is weak, attackers may be able to forge valid-looking tokens or brute-force the signing key far more easily than teams expect.
That is why long random secrets are the boring, correct default. Human-readable project names, short environment variables, and “temporary” values from examples should never become production signing keys.
A practical workflow for choosing secret length
- Identify the secret type. Password, API key, JWT signing secret, webhook token, and encryption key do not all behave the same way.
- Use a random generator, not your keyboard. Human creativity is not a security primitive.
- Pick a length with margin. For modern app secrets, erring upward is usually cheaper than erring downward.
- Store it safely. Secret managers, environment injection, and access controls matter as much as the initial value.
- Rotate when exposed or reused too broadly. A strong secret that leaked is no longer a strong secret operationally.
Operational questions worth asking
| Question | Why it matters |
|---|---|
| Will humans ever type this by hand? | If not, there is little reason to optimize for shortness. |
| Could forgery or disclosure create major risk? | Higher impact should push you toward stronger defaults and faster rotation. |
| Will this secret be copied across many systems? | Broader spread increases operational exposure if the value leaks. |
| Is the secret generated once or rotated regularly? | Lifecycle discipline matters as much as the initial length choice. |
A boring default is usually a good default
If you are not under a special legacy constraint, long random secrets generated by a trusted tool are almost always the correct choice. They are not glamorous, but they remove a surprising number of avoidable debates and mistakes.
Security failures in this area rarely come from overestimating entropy. They usually come from optimizing for convenience until the value stops being meaningfully secret.
Common misconceptions
Character variety helps, but randomness matters more than decoration.
A weak secret remains weak if the attacker can guess the original input.
Environment separation and rotation exist for a reason.
Temporary shortcuts are how weak values survive into long-lived systems.
Why weak secrets often survive review
Weak secrets rarely announce themselves dramatically. They survive because they look plausible enough: a mixed-case string, a project name with a number appended, or a copied example that nobody revisits after launch day. In fast-moving teams, anything that appears to work can remain untouched for months or years.
That is why a review habit matters more than individual cleverness. Security gets better when teams normalize asking where the value came from, whether it was generated randomly, how broadly it is reused, and whether rotation would be painful if compromise were suspected tomorrow.
Length decisions should match operational reality
If a secret will only ever live in a vault, CI system, or environment variable, there is almost no operational upside to making it short. Humans are not memorizing it, support staff are not typing it, and users never see it. In those cases, longer random values are effectively a free upgrade.
The few cases that really do have constraints are usually legacy integrations, device firmware fields, or awkward admin panels with tight limits. Even there, the right response is to find the strongest value the system supports, document the limitation clearly, and plan to remove the constraint rather than pretending the limit is somehow a best practice.
A compact review rule for teams
The safest default is usually the least imaginative one
Security guidance in this area becomes much simpler when teams stop trying to be clever. You do not need a memorable formula, a branded naming trick, or a handcrafted “complex” string. You need a strong random value of adequate length, generated by a trustworthy tool, stored properly, and replaced when its exposure story changes.
That is what the boring default really means: choose the path with the fewest opportunities for human improvisation to weaken the result. Boring is good when the alternative is accidental predictability.