Two RFC 8725 rules get less attention than the none algorithm warning. Do not use a human-memorable password directly as an HMAC key, and do not compress plaintext before encrypting it. Both are about leaking information through weak key material or through output size.
Rule one: key entropy
RFC 8725 says to ensure sufficient key entropy. Passwords should not be used directly as HMAC keys. If a password must be used at all, it should be used only for key encryption, and even then it remains vulnerable to brute force.
The reason is simple. A signature with HS256 is only as strong as the secret. If the secret is a short word or an environment name, anyone who sees a token can try guesses offline and check each against the signature. No rate limit slows them down because no server is involved.
What a good HMAC key looks like
- Random bytes from a cryptographically secure generator, not typed by a person.
- Long enough for the algorithm. Match the key length to the hash size as a baseline, and follow the library guidance for your algorithm.
- Stored in a secrets manager or key service, not in source code.
- Unique per environment and per purpose.
If you inherit a project with a readable string such as a project name as the JWT secret, treat it as compromised and rotate it. Plan for existing tokens: either let them expire or run old and new keys together for a short window.
Rule two: no compression before encryption
RFC 8725 says to avoid compression of data before encryption. Compressing plaintext before encrypting it can leak information about the content, because the size of the output changes depending on what the data contains. An observer who can influence part of the plaintext and watch the ciphertext length may be able to learn about the secret parts.
This applies to JWE, the encrypted form of JWT, which has an optional compression parameter. If your library offers it, leave it off unless you have analysed the risk.
Why design for a swap
The RFC also advises that implementations be designed for algorithm agility and accept only strong algorithms. If a secret is weak today, you want to be able to move to an asymmetric algorithm or a new key without rewriting every consumer.
Choosing between shared secrets and key pairs
A shared HMAC secret means every verifier can also forge tokens. If many services verify, the secret spreads. An asymmetric algorithm lets verifiers hold only a public key. For systems with several consumers, asymmetric signing limits the damage from one compromised verifier. The RFC's guidance to bind each key to one algorithm applies either way.
A short review
- Find every place your code builds or loads a JWT secret.
- Confirm it is generated randomly and stored in a proper secret store.
- Confirm no compression option is enabled on encrypted tokens.
- Confirm the allowed algorithm list is explicit.
- Write a test that fails if the secret is shorter than your minimum.
Quick check
Can I derive an HMAC key from a password with a KDF?
The RFC says passwords may be used for key encryption but remain vulnerable to brute force. Prefer random keys. If you must use a password, use a proper password based derivation and treat it as the weaker option.
Is signing-only JWT affected by the compression rule?
The rule is about compressing before encryption. A signed-only token has no encryption layer, but its payload is readable by anyone, so never put secrets in it.
Safeguard's dependency scanning shows which JWT libraries and versions your services use, and the free scan at gold.safeguard.sh/scan is a quick start.
Sources
Last reviewed: 19 October 2026.
