Loading...
Loading...
Securely share JWT signing secrets and authentication keys with your development team.
A JWT signing secret is the cryptographic root of trust for every authenticated session your app issues. RFC 7519 defines the token format, RFC 7515 the signature envelope, and the header `alg` decides what a leak means. Under HS256 one shared secret signs and verifies — leak it and an attacker mints a token for any `sub` or `role`, with nothing unusual in the log. Under RS256 or ES256 only the private key signs; the public half (a JWK per RFC 7517) is meant to be published.
Posting `JWT_SECRET=...` into Slack, a Jira comment, or a Notion `.env` attachment creates the wrong distribution surface. Workspace exports keep the value in compliance archives. Scanners like TruffleHog and GitHub push-protection alert on `eyJhbGciOi`-style patterns, but only after the secret hits a tracked surface — damage from a chat paste lands first.
PasteOnce fits the moment a signing secret moves between humans, or between an operator and an HSM bootstrap script. Generate with `openssl rand -base64 64`, paste, deliver out-of-band, and rotate the issuer's material once import is confirmed. Long-term the signing key belongs in AWS KMS, Google Cloud KMS, or Vault Transit — services that sign without releasing private bytes.
Client-side encrypted. We can't see your data.
Your data is encrypted in your browser before it leaves your device.
Messages are automatically deleted after being read once.
We never see your data. Only encrypted blobs pass through our servers.
Links work exactly once. Refresh the page and it's gone forever.
Your sensitive data is encrypted in your browser using AES-256-GCM. The encryption key is generated randomly and never sent to our servers.
Only the encrypted blob is stored in our database, with an automatic expiration time. We literally cannot read your data.
When your recipient opens the link, the encrypted data is fetched and immediately deleted from our servers using an atomic Redis GETDEL. The key in the URL hash decrypts the message in their browser.
Where a microservice, mobile app, or third-party integration must verify tokens, asymmetric is the only sane choice. Generate Ed25519 with `openssl genpkey -algorithm ed25519`, keep the private half in KMS, let consumers pull the public half from JWKS.
Every minted token should carry a `kid` value (UUID, timestamp, anything stable). Verifiers select the matching JWK from JWKS by `kid`. Adding a new key becomes a config change rather than a flag-day rollout.
AWS KMS, Google Cloud KMS, and Azure Key Vault expose a `Sign` operation returning a signature without releasing the private key. `aws-jwt-verify` and `jose` support this directly; a stolen `.env` then yields nothing.
Pass `algorithms: ['RS256']` to `jose.jwtVerify`, `jsonwebtoken.verify`, or `PyJWT.decode`. Never trust the algorithm from the token header — that is how alg=none and HS-vs-RS confusion succeed. Pin once, audit on every dependency upgrade.
Platform adds a fifth service to the auth fabric and it needs the cluster's HS256 secret to verify gateway tokens. The lead pastes on a one-hour TTL; the recipient drops it into a Kubernetes Secret via `kubectl create secret` and the link is gone before deployment finishes.
A scan flags that the issuer's private key was briefly committed to a public Gist. On-call generates a fresh Ed25519 keypair in KMS, publishes it under a new `kid`, and PasteOnces the rotation runbook to the deputy at 2 AM.
A SaaS vendor signs outbound webhooks with a JWT carrying tenant ID. Onboarding a new customer needs the per-tenant HS256 secret delivered once. PasteOnce carries it, the customer pins the value in their verifier, and the link self-destructs before the first call.
HS256 uses one shared secret for signing and verification — fast and catastrophic if it leaks. RS256 (and ES256, EdDSA) uses an asymmetric keypair: only the private half signs, the public half verifies and ships as a JWK at a JWKS endpoint. Pick HS256 only when issuer and verifier sit inside one trust boundary.
For HS256 use at least 256 bits of real entropy — `openssl rand -base64 64` produces 512 bits, a sensible floor for HMAC-SHA256 per RFC 2104. Anything under 32 bytes invites offline brute force. For RS256 use 2048-bit keys minimum; ES256 fixes the size at 256 bits via the curve.
Not against a correctly configured verifier. Historic attacks — alg=none in `jsonwebtoken` before 4.2.2, RS256-to-HS256 confusion in older `PyJWT` — exploited libraries that trusted the token header to pick the algorithm. Pin the algorithm in your verify call and the only forgery path left is a leaked key.
Yes — make rotation routine, not incident-driven. Use the `kid` header from day one so adding a new key is a config change. A reasonable cadence is quarterly for HS256, annually for RS256 keypairs, with immediate rotation on suspected exposure.