JWT Signature Cracker
Test JWT security with dictionary-based signature cracking. Supports HS256, HS384, and HS512 algorithms with built-in common passwords and custom wordlists.
Educational Use Only: Only test JWTs you own or have written permission to test. Unauthorized testing is illegal.
JWT Signature Cracker: Test JWT Security with Dictionary Attacks (Educational)
Educational JWT cracking tool for security testing and penetration testing. Test the strength of HMAC JWT secrets using dictionary attacks with 10,000+ common passwords or custom wordlists. Supports HS256, HS384, and HS512 algorithms with concurrent workers for fast performance.
⚠️ Legal & Ethical Use Only
This tool is provided for educational purposes, authorized security testing, and penetration testing only. Only test JWTs you own or have explicit written permission to test. Unauthorized JWT cracking is illegal under computer fraud laws including the Computer Fraud and Abuse Act (CFAA).
Use cases: CTF competitions, security research, vulnerability assessments with authorization, penetration testing engagements, educational training.
What Is JWT Signature Cracking (And Why Test It)?
JWT (JSON Web Token) signature cracking is the process of discovering the secret key used to sign HMAC-based JWTs through dictionary or brute-force attacks. JWTs signed with weak secrets like "password" or "secret" are vulnerable to cracking, allowing attackers to forge arbitrary tokens and bypass authentication—a critical security flaw according to OWASP's JWT Testing Guide.
This tool tests HMAC algorithms (HS256/SHA-256, HS384/SHA-384, HS512/SHA-512) by attempting thousands of passwords per second using concurrent workers. If your JWT secret appears in common password lists, it can be cracked in seconds—exposing your application to complete authentication bypass. The tool demonstrates why strong, random secrets (256+ bits) are essential for production JWT implementations.
Why JWT Security Testing Matters for Developers:
Detect Weak Secrets
- • Audit JWT implementations: Test if production secrets are strong
- • Prevent authentication bypass: Weak secrets = total system compromise
- • Compliance requirements: OWASP/NIST mandate strong cryptographic keys
- • Penetration testing: Validate JWT security in security assessments
Educational Value
- • Learn JWT internals: Understand HMAC signature verification
- • Security awareness: See why dictionary passwords fail instantly
- • CTF competitions: Practice JWT exploitation techniques legally
- • Best practices: Learn proper JWT secret generation methods
Real JWT Cracking Examples
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4ifQ.9M3lH... Secret: "password" - Found in top 10 common passwordseyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4ifQ.aB9dF... Secret: 64-byte random hex - Resistant to dictionary attackseyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... RS256 uses public/private key pairs, not dictionary attackableeyJhbGciOiJub25lIiwidHlwIjoiSldUIn0... Accepts unsigned tokens - always rejected by this toolHow to Test JWT Security in 3 Simple Steps
💡 Pro Tip: Testing Your Own JWTs
Generate test JWTs with weak secrets to practice: openssl rand -base64 32 creates strong secrets, while password demonstrates weakness. Sign tokens using jwt.io and test against this tool to validate your organization's JWT security posture.
JWT Algorithms: HMAC vs Asymmetric (Security Comparison)
Uses a shared secret key for both signing and verifying tokens. Produces 256-bit (32-byte) signatures. Vulnerability: If the secret is weak or compromised, attackers can forge tokens. Recommended secret length: 256 bits (64 hex characters) per RFC 7518. Fast performance but requires secure secret distribution.
Uses SHA-384 hash function producing 384-bit (48-byte) signatures. More secure than HS256 with longer output but requires 384-bit secrets. Slightly slower but provides better collision resistance. Useful for high-security applications where performance is less critical. Still vulnerable to dictionary attacks if weak secrets are used.
Uses SHA-512 hash function producing 512-bit (64-byte) signatures. Strongest HMAC variant with highest collision resistance. Recommended for maximum security in symmetric JWT scenarios. Requires 512-bit (128 hex character) secrets. Best choice when using HMAC algorithms, but asymmetric algorithms (RS256, ES256) are more secure overall.
Uses RSA public/private key pairs. Signed with private key, verified with public key. Not vulnerable to dictionary attacks because verification uses public key only. Recommended for production per Auth0's security guidelines. Slower than HMAC but eliminates shared secret distribution problems. Use 2048-bit RSA minimum (4096-bit recommended).
Uses Elliptic Curve Digital Signature Algorithm with P-256 curve. Provides equivalent security to 3072-bit RSA with smaller 256-bit keys, resulting in faster operations and smaller signatures. Recommended for modern applications requiring high performance and security. Supported by all major JWT libraries and increasingly preferred over RS256.
⚠️ Algorithm Selection Best Practices
- • Production systems: Use RS256 or ES256 (asymmetric) to eliminate secret sharing risks
- • If using HMAC: Generate secrets with
openssl rand -hex 64(512 bits) - • Never use: "none" algorithm, dictionary words, or predictable patterns as secrets
- • Rotate secrets: Change HMAC secrets every 90 days; rotate asymmetric keys annually
How JWT Dictionary Attacks Work (Technical Deep Dive)
Understanding the cracking process helps developers build more secure JWT implementations. Here's the step-by-step technical process this tool uses to crack HMAC JWT signatures:
The tool splits the JWT into three Base64URL-encoded segments: header.payload.signature. It decodes the header to extract the algorithm (must be HS256, HS384, or HS512). The signing input (header + "." + payload) is preserved for signature computation.
Loads the selected wordlist: 10,000+ common passwords from RockYou breach data, OWASP password lists, and pattern variations (password1, password123, etc.), or your custom uploaded wordlist (up to 1 million passwords). Passwords are preprocessed to remove duplicates and empty lines for efficiency.
Spawns 8 concurrent goroutine workers that test passwords in parallel. For each candidate password, the tool computes HMAC-SHA896(header.payload, secret) using Go's crypto/hmac package. Modern CPUs can test 50,000-100,000 passwords per second.
Each computed signature is compared with the original JWT signature using subtle.ConstantTimeCompare() to prevent timing attacks. This ensures even the cracking tool follows security best practices. If signatures match (all 256/384/512 bits identical), the secret is found.
When a match is found, all workers immediately terminate using context cancellation (no wasted CPU cycles). Results include the cracked secret, algorithm, total attempts, elapsed time, and attempts per second. If no match after exhausting the dictionary, the tool reports failure—indicating the secret is strong or not in the wordlist.
🔍 Why Weak Secrets Fail So Quickly
Common passwords like "password", "secret", "admin" appear in the top 100 entries of attack dictionaries. With 100,000 attempts/sec performance, these are cracked in under 1 millisecond. Even "complex" but predictable patterns like "Password123!" or "Admin@2024" are in expanded wordlists and crack in under 1 second.
Contrast this with properly generated secrets: openssl rand -hex 32 produces 2256 possible values (1.16 × 1077). At 100,000 attempts/sec, cracking would take longer than the age of the universe.
JWT Security Best Practices for Developers
Based on OWASP JWT Security Cheat Sheet and industry standards, follow these guidelines to secure your JWT implementations:
✓ DO: Secure JWT Implementation Checklist
- ✓ Use asymmetric algorithms: Prefer RS256 or ES256 over HMAC to eliminate shared secrets
- ✓ Generate strong HMAC secrets: Use cryptographically random 256-bit (HS256), 384-bit (HS384), or 512-bit (HS512) secrets
- ✓ Store secrets securely: Use environment variables, AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault—never hardcode
- ✓ Implement token expiration: Set short
expclaims (15-60 minutes) and use refresh tokens - ✓ Validate algorithm: Explicitly check
algheader matches expected value (prevent algorithm confusion) - ✓ Use HTTPS only: Always transmit JWTs over TLS to prevent interception
- ✓ Implement token revocation: Maintain blocklists or use short-lived tokens with refresh mechanisms
- ✓ Rotate secrets regularly: Change HMAC secrets every 90 days; rotate asymmetric keys annually
- ✓ Validate all claims: Check
iss,aud,exp,nbfclaims per RFC 7519
✗ DON'T: Common JWT Security Mistakes
- ✗ Never accept "none" algorithm: Always reject
alg: "none"to prevent unsigned token attacks - ✗ Don't use weak HMAC secrets: Avoid dictionary words, names, dates, or predictable patterns
- ✗ Never store secrets in code: Hardcoded secrets in repositories are exposed immediately
- ✗ Don't skip signature verification: Always validate signatures before trusting token contents
- ✗ Avoid storing sensitive data: JWTs are Base64-encoded (not encrypted)—visible to anyone with the token
- ✗ Don't use unlimited expiration: Tokens without
expclaims are valid forever if compromised - ✗ Never mix public/private keys: Don't confuse asymmetric public keys with HMAC secrets
- ✗ Don't ignore algorithm header: Validate
algto prevent algorithm substitution attacks
Code Example: Secure JWT Secret Generation
Generate cryptographically secure HMAC secrets using these commands:
# HS256 (256-bit secret - 64 hex characters)
openssl rand -hex 32
# Output: a7f3d9c2e1b4f8a6d5c9e2f1b7a4d8c3e6f9b2a5d8c1e4f7b9d2a6e8c5f1b4d7# HS384 (384-bit secret - 96 hex characters)
openssl rand -hex 48# HS512 (512-bit secret - 128 hex characters)
openssl rand -hex 64Common JWT Cracking Use Cases (Legitimate Only)
Penetration Testing
Security consultants use JWT cracking during authorized penetration tests to identify weak secrets in client applications. Test findings help organizations strengthen authentication before attackers exploit vulnerabilities. Always obtain written authorization.
Security Research & CTF
Researchers study JWT vulnerabilities to improve security standards. CTF (Capture The Flag) competitions include JWT cracking challenges to teach security concepts. This tool is perfect for learning JWT internals and practicing ethical hacking skills legally.
Development & Testing
Developers test their own JWT implementations during development to verify secret strength before production deployment. Generate test tokens with known weak secrets to validate application security and ensure proper secret rotation procedures are in place.
Security Audits
Security teams audit internal applications to ensure compliance with security policies. Testing JWT secrets against common dictionaries validates that development teams follow cryptographic best practices and use properly generated random secrets.
Frequently Asked Questions (FAQ)
What is the difference between JWT cracking and JWT decoder tools?
JWT decoders simply Base64-decode the header and payload to display contents—no security testing involved. JWT crackers attempt to discover the secret key through brute-force or dictionary attacks to demonstrate weak secret vulnerabilities. Decoders are for inspection; crackers are for security testing.
How long does it take to crack a JWT with a strong secret?
Properly generated secrets (256+ bits of cryptographic randomness) are computationally infeasible to crack—trillions of years at current computing power. Weak secrets like "password" crack in milliseconds, "Admin2024!" in seconds, but "a7f3d9c2e1b4f8a6..." (hex random) is uncrackable. This is why OWASP recommends openssl rand for secret generation.
Can this tool crack RS256, RS384, RS512, or ES256 JWTs?
No. This tool only cracks HMAC-based algorithms (HS256, HS384, HS512) that use shared secrets. Asymmetric algorithms (RS256, ES256) use public/private key cryptography—verification uses the public key, which doesn't help crack the private signing key. Asymmetric algorithms are immune to dictionary attacks, which is why they're recommended for production systems.
Is JWT cracking legal?
JWT cracking is legal only with explicit authorization. Legitimate uses include: testing your own applications, authorized penetration testing engagements, CTF competitions, and security research on sample tokens. Cracking JWTs without permission violates computer fraud laws (CFAA in US, CFAA equivalents globally) and can result in criminal prosecution. Always obtain written authorization.
How do I protect my application from JWT cracking attacks?
Use RS256 or ES256 (asymmetric algorithms) instead of HMAC. If HMAC is required, generate secrets with openssl rand -hex 64 (512 bits). Store secrets in environment variables or secret managers (never code). Implement short token expiration (15-60 minutes). Rotate secrets quarterly. Monitor for suspicious authentication patterns. See our PBKDF2 Generator for password hashing best practices.
What makes a JWT secret "strong enough"?
For HS256: 256 bits (32 bytes) of cryptographic randomness. For HS384: 384 bits (48 bytes). For HS512: 512 bits (64 bytes). Generated using openssl rand, crypto.getRandomValues(), or language-equivalent CSPRNGs. Never use passwords, dictionary words, names, dates, UUIDs, or anything predictable. Strong secrets resist all dictionary and brute-force attacks with current computing technology.