skip to content

Why is a short HMAC secret dangerous for an HS256-signed JWT?

level: middleimportance: should knowfreq 55%

answer

  1. The verifier can also mint
  2. Guessing happens on the attacker's machine
  3. No lockout, no logging, no rate limit
  4. Generated beats memorable
  5. Key at least the hash output size

basics

~20 s

An attacker holding one token can guess the secret offline at full speed, because every candidate is checked locally against a known signature. A dictionary word or short string falls quickly, and the secret is also the signing key — so cracking it means minting valid tokens.

solid answer

~50 s

With a symmetric algorithm the same secret verifies and signs, so recovering it is a complete compromise: the attacker can mint tokens for any subject with any claims. Recovery is easy when the secret is weak because the attack is entirely offline — one captured token gives the attacker `header.payload` and the expected MAC, so they iterate candidate secrets locally with no rate limiting, no lockout and no logs, at hardware speed. Passphrases like `secret`, a project name, or a default from a tutorial fall in seconds. The JOSE algorithm specification requires an HMAC key at least as long as the hash output — 256 bits for HS256 — and the practical rule is to generate that from a cryptographic random source, store it as a managed secret, never commit it, and rotate it. Systems that need many verifiers should prefer an asymmetric algorithm so verifiers never hold signing power.

code

bash · 2 lines
bash
# generate a 256-bit signing secret from a cryptographic source
openssl rand -base64 32

go deeper

for a junior

Know that HS256 uses one shared secret for signing and verifying, that it must be long and randomly generated, and that it never belongs in source control.

for a middle

Explain why cracking is offline and fast — the attacker holds the signing input and its MAC, and HMAC-SHA256 has no work factor — plus the 256-bit minimum for HS256.

for a senior

Cover operations: per-environment secrets, storage in a secret manager, dual-secret rotation with an overlap window, secret scanning, and treating any exposure as immediate compromise.

for a principal

Own the algorithm choice. Argue that symmetric signing distributes minting authority to every verifier and does not scale across service boundaries, and set an asymmetric default with the issuer as the only private-key holder.

## Why symmetric signing raises the stakes HS256 computes an HMAC over `base64url(header) + "." + base64url(payload)` using a shared secret. Verification recomputes the same value with the same secret. There is no asymmetry: **anyone who can verify can also sign**. So the secret is not merely a verification input — it is minting authority for the whole system. Compromise it and the attacker issues tokens for any subject, with any roles, and any expiry, indistinguishable from real ones. ## The attack is offline, and that changes everything Guessing an online password is slow: the server rate-limits, locks accounts, and logs failures. None of that applies here. An attacker who captures a single token — from a client, a log file, a browser, a shared trace — holds both the message and its correct MAC. They can now test candidate secrets entirely on their own hardware: 1. Take a candidate secret. 2. Compute HMAC-SHA256 over the token's signing input. 3. Compare with the signature segment. 4. Repeat. Each test is one cheap hash. HMAC-SHA256 is deliberately *fast*, which is right for its purpose and terrible when it is used as a password check. There is no memory-hard function, no salt, no work factor — the properties that make password hashing slow are absent by design. Standard cracking tools consume JWTs as an input format, and wordlists plus rule-based mutations cover the space humans actually choose from. That means the practical distinction is not "short versus long" but **"chosen by a human versus generated by a machine"**. `Sup3rS3cret!2024` is 16 characters and falls to a rule-based dictionary attack; 32 bytes from a cryptographic random generator does not fall to anything. ## The specified minimum The JOSE algorithms specification is explicit: a key used with HMAC must be at least the size of the hash output — 256 bits for HS256, 384 for HS384, 512 for HS512 — and keys shorter than that must be rejected. Good libraries enforce it and throw when handed a short secret; a library that silently accepts an eight-character string is doing you no favours. Note that the requirement is on **entropy-bearing key material**, so a 32-character English passphrase satisfies the length rule on paper while carrying far less than 256 bits of actual entropy. ## Where weak secrets come from in practice Almost never from a deliberate decision. The recurring sources are: - A tutorial default (`secret`, `changeme`, `your-256-bit-secret`) copied into a config file and shipped. - A value committed to the repository "temporarily", then inherited by every environment and every developer, and preserved forever in git history. - The same secret across development, staging and production, so a compromise of the least-protected environment mints production tokens. - A human-memorable string chosen so that someone could type it during an incident. ## Doing it properly - **Generate** at least 32 bytes from a cryptographically secure random source and encode for storage; do not type a passphrase. - **Store** it in a secret manager or injected environment configuration, never in source control, never in a container image layer, never in a client-side bundle. - **Separate** secrets per environment so a staging leak cannot mint production tokens. - **Rotate** on a schedule and on any suspicion of exposure; support two active secrets during the overlap so tokens signed before rotation still verify until they expire. - **Scan** for leaked secrets in commits and build artefacts, and treat any appearance in a log or ticket as a compromise requiring rotation. ## Prefer asymmetric when there are many verifiers The deeper design point: with HS256 every service that must verify tokens has to hold the signing secret, so the number of places holding minting authority equals the number of verifiers. That scales badly and violates least privilege. With RS256 or ES256 the issuer holds the private key alone and verifiers hold only public keys, which can be published freely. Symmetric signing is defensible when issuer and verifier are the same component and the secret never leaves it; it becomes a liability as soon as tokens cross a service boundary. ## Answering it well Name the two facts that make it dangerous — the secret is also minting authority, and cracking is offline against a fast hash — then give the concrete standard (256 bits for HS256, generated not chosen), and close with the architectural point about asymmetric algorithms once more than one service verifies. That progression takes the answer from "use a long secret" to a real understanding of the threat.

  • Why does the attacker not need to interact with your service to crack the secret?
    One captured token supplies both the signing input and the expected MAC, so every candidate secret can be tested locally. There is no request to rate-limit, no account to lock, and nothing appears in your logs. Detection is effectively impossible, which is why the strength of the key material has to carry the whole defence.
  • A 32-character passphrase meets the length requirement. Is it good enough?
    Not necessarily. The specification's requirement is about key size, but security depends on entropy, and human-chosen passphrases fall to dictionary and rule-based attacks well below their nominal length. Generate 32 bytes from a cryptographic random source instead; there is no reason for a machine-only secret to be memorable.
  • How do you rotate an HMAC signing secret without invalidating tokens in flight?
    Keep two secrets active: sign only with the new one, but accept either during an overlap window at least as long as the maximum token lifetime, then retire the old one. If you must invalidate everything immediately — a suspected leak — drop the old secret at once and accept that every outstanding token is rejected, which is the intended outcome.
  • When is HS256 still a reasonable choice?
    When the issuer and the verifier are the same component, or a small trusted set under one owner, and the secret never crosses a service boundary. It is simpler and has no key distribution problem. Once several independently deployed services must verify, switch to an asymmetric algorithm so verifiers hold only public keys and cannot mint tokens.

saying these in an interview costs you the question

  • Uses a memorable passphrase as the signing secret
  • Thinks rate limiting protects the secret from guessing
  • Shares one secret across all environments
  • Believes HS256 is broken rather than the key being weak
  • Gives every verifying service the signing secret

context

resolving links…