DEV Community: ReplikanteK

What Is a JWT and How to Inspect Its Security Claims

ReplikanteK — Sun, 31 May 2026 09:31:03 +0000

What Is a JWT and How to Inspect Its Security Claims

May 31, 202610 min read

JSON Web Tokens (JWTs) are everywhere — API authentication, single sign-on, session management. But most developers never look inside them. That is a mistake. A misconfigured JWT can give an attacker full access to any account, bypass signature verification entirely, or escalate privileges with a single header change.

This guide explains what a JWT is, how to decode it, and what security claims to inspect. You will learn to spot the misconfigurations that matter — using the JWT Decoder from SecuriTool, all client-side.

Open the JWT Decoder in another tab while you read:

JWT Decoder →

What Is a JWT?

A JWT is a compact, URL-safe token format defined in RFC 7519. It carries claims (statements) about an entity — typically a user — and is signed so the recipient can verify it was issued by a trusted source.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Three Base64-encoded parts separated by dots:

PartContainsExample Content
HeaderAlgorithm and token type{"alg":"HS256","typ":"JWT"}
PayloadClaims (user data, permissions, timestamps){"sub":"1234567890","admin":true}
SignatureCryptographic verificationHMAC-SHA256(header + payload, secret)

Why Inspect JWT Security Claims?

JWTs are only as secure as their configuration. The most common vulnerabilities come from the header and payload claims — not from broken cryptography. Security researchers look for:

ClaimRisk if MisconfiguredImpact
algnone bypasses signature verification entirelyFull authentication bypass
kidPath injection or SQL injection via key IDCode execution, data leak
jwk / jkuAttacker supplies their own signing keyToken forgery
expMissing expiration = token valid foreverPermanent session hijack
iss / audMissing validation = cross-tenant token reuseAccount takeover across tenants
role / adminServer trusts client-provided privilege claimsPrivilege escalation

Step-by-Step: Decode a JWT

Copy any JWT from an Authorization: Bearer header, cookie, or URL parameter.
Paste it into the JWT Decoder at securitool.js.org.
Read the decoded header and payload instantly.
Check the critical claims listed above.

Everything happens client-side. No token data leaves your browser.

Header Claims: What to Check

The `alg` claim

The algorithm claim tells the server how to verify the token. This is the most attacked JWT field.

{
  "alg": "HS256",
  "typ": "JWT"
}

Red flags:

alg: "none" — Signature verification completely disabled. The server accepts any token without checking the signature. This is the most critical JWT vulnerability.
alg: "HS256" with a public key in jwk — Algorithm confusion. The server expects RSA but the attacker signs with HMAC using the public key as the secret.
alg switches between RSA and HMAC across different endpoints — inconsistent verification.

The `kid` claim

Key ID tells the server which key to use for verification. It is often used as a file path or database lookup.

{
  "alg": "RS256",
  "kid": "key-2024"
}

Red flags:

Path traversal: "kid": "../../dev/null" — trick the server into using /dev/null (empty key) for verification.
SQL injection: "kid": "key' OR '1'='1" — manipulate the key lookup query.
Command injection: "kid": "|ls -la" — if the server passes kid to a shell command.

The `jwk` and `jku` claims

These claims tell the server where to find the signing key. An attacker can point them to their own key server.

{
  "alg": "RS256",
  "jku": "https://attacker.com/keys.json"
}

Attack: The server fetches the attacker's public key and uses it to verify the attacker's token — which was signed with the attacker's private key.

Payload Claims: What to Check

Missing expiration (`exp`)

{
  "sub": "user123",
  "iat": 1516239022
}

If there is no exp claim, the token never expires. An attacker who steals it has permanent access.

Missing issuer/audience validation

{
  "sub": "user123",
  "name": "John Doe"
}

Without iss (issuer) and aud (audience), a token issued by Service A can be used to access Service B. This is critical in microservice architectures.

Privilege claims

{
  "sub": "user123",
  "admin": true,
  "role": "superadmin"
}

If the server trusts these client-provided claims without checking its own database, an attacker can modify the payload and escalate privileges.

Common JWT Attack Patterns

AttackHow It WorksDetection
alg:noneRemove signature, set alg: "none"Server accepts unsigned tokens
Key confusionUse RSA public key as HMAC secretAlgorithm switches between RSA and HMAC
Kid injectionPath traversal in kid parameterTest ../../etc/passwd
Weak secretBrute-force HMAC secret with wordlistsCommon passwords like secret, password
JKU redirectPoint jku to attacker-controlled URLServer fetches external key

Real-World Example

Decode this token:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.

Header: {"alg":"none","typ":"JWT"} — the none algorithm means no signature verification.

Payload: {"sub":"1234567890","name":"John Doe","admin":true} — admin flag set to true.

Signature: Empty string after the second dot.

Verdict: This token bypasses all authentication. Any server that does not explicitly reject alg: none will accept it as valid.

What the Tool Cannot Do

Cannot verify signatures — the decoder shows the decoded content but does not validate whether the signature is correct. You need the server's public key or secret for that.
Cannot detect server-side misconfigurations — if the server accepts alg: none, you can only find out by testing against the actual API.
Cannot decrypt encrypted JWTs (JWE) — JWE tokens are encrypted, not just signed. The decoder will show the encrypted envelope.

Conclusion

JWT security is not about broken cryptography — it is about misconfigured claims. A single missing exp or a permissive alg: none can compromise an entire authentication system.

By decoding every JWT you encounter and checking the critical claims, you can spot vulnerabilities that most developers miss.

Try it with your own tokens:

Decode any JWT:

JWT Decoder →

Test for attacks (alg:none, kid injection, secret cracking):

JWT Attacker →

Published May 31, 2026 · Practical Guide · SecuriTool

How to Identify Hash Types: A Step-by-Step Guide

ReplikanteK — Thu, 28 May 2026 10:32:33 +0000

How to Identify Hash Types: A Step-by-Step Guide

May 28, 20268 min read

When you encounter an unfamiliar string of characters during a penetration test or a CTF challenge, the first question is always: what type of hash is this? Identifying the hash type determines which cracking tool to use, what attack vectors apply, and how much effort it will take to reverse it.

This guide shows you how to identify 40+ hash types by analyzing their length, character set, and prefix patterns using the Hash Identifier from SecuriTool — all in your browser, no data sent to any server.

Open the Hash Identifier in another tab while you read:

Hash Identifier →

How Hash Identification Works

Hash identification relies on three characteristics:

Clue	What It Tells You	Example
Length	Number of characters in the hex/base64 string	32 chars → MD4/MD5/NTLM
Character set	Hex (0-9a-f), Base64 (A-Za-z0-9+/), or custom	Hex 40 chars → SHA-1
Prefix / Format	Special markers like $2y$ , $6$ , `{SSHA}`	$2y$ → bcrypt

The Hash Identifier applies pattern matching across all three dimensions and returns a confidence score for each possible match.

Step 1: Paste the Hash

Go to the Hash Identifier page. Paste your unknown string into the text area and click Identify.

The tool processes everything client-side — your hash never leaves your browser.

Step 2: Read the Results

The output lists possible matches sorted by confidence score, with a visual progress bar:

→ bcrypt (60 chars) ████████░░ 86%
  Unix SHA-512 (crypt) (106 chars) ██████░░░░ 62%
  SHA-512 (128 chars) █████░░░░░ 50%

The arrow marks the best match. The percentage reflects how well the hash matches all detection criteria (length, regex pattern, and prefix).

Step 3: Identify by Length

Hash length is the fastest way to narrow down possibilities. Here is a quick reference:

Length (hex)	Likely Hash Types	Use Case
`8`	CRC32, Adler32	Checksums, error detection
`16`	MySQL ≤ 4.1	Legacy MySQL password hashes
`32`	MD4, MD5, NTLM, LM, RIPEMD-128	Legacy auth, Windows passwords
`40`	SHA-1, RIPEMD-160, PBKDF2-HMAC-SHA1	Git commits, SSL certs, legacy APIs
`56`	SHA-224, SHA3-224, SHA-512/224	FIPS compliance, blockchain
`64`	SHA-256, SHA3-256, RIPEMD-256, GOST 256, PBKDF2-HMAC-SHA256	Modern applications, TLS, Bitcoin
`96`	SHA-384, SHA3-384	High-security, gov standards
`128`	SHA-512, SHA3-512, Whirlpool, GOST 512	Maximum security, DNSSEC

Step 4: Identify by Prefix

Password hashing algorithms use distinctive prefixes that make them instantly recognizable:

Prefix	Hash Type	Format Example
$2y$ , $2a$ , $2b$	bcrypt	`$2y$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy`
$6$	Unix SHA-512 crypt	`$6$rounds=1000$salt$hash`
$5$	Unix SHA-256 crypt	`$5$rounds=5000$salt$hash`
$1$	Unix MD5 crypt	`$1$salt$hash`
`$argon2`	Argon2	`$argon2id$v=19$m=65536,t=3,p=4$...$...`
$SHA$	bcrypt (SHA-256 variant)	`$SHA$salt$hash`
`scrypt:`	scrypt	`scrypt:16384:8:1$...$...`
`*` (leading asterisk)	MySQL 5+	`*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4`
`0x`	Ethereum address	`0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18`

Step 5: Read a Real-World Example

Let us identify this hash:

$2y$12$LJ3m4ys3Lk0TSwHnbfOMiOXPm1Qm0M0v0M.0M0M0M0M0M0M0M0M0M0

Step 1: Length is 60 characters — too short for SHA-512 (128), too long for MD5 (32).

Step 2: Contains $2y$ prefix followed by two cost digits 12$.

Step 3: Uses A-Za-z0-9./ character set (Base64 variant).

Result: bcrypt with cost factor 12. Used by most modern web frameworks for password storage (Rails, Django, Node.js, PHP).

Quick Reference: Common Hash Patterns

Password hashes (modern):
$2y$10$... → bcrypt · $argon2id$... → Argon2id · $6$... → SHA-512 crypt

Windows authentication:
32-char hex → NTLM (aad3b435b51404eeaad3b435b51404ee)
32-char uppercase hex → LM hash

Web frameworks:
32-char hex → MD5 (WordPress, Joomla, vBulletin legacy)
40-char hex → SHA-1 (GitHub, Docker hub)

Blockchain / Crypto:
64-char hex → SHA-256 (Bitcoin)
1 or 3 followed by 25-34 chars → Bitcoin address
0x + 40 hex → Ethereum address

When Lengths Overlap

Some hash lengths map to multiple types. A 32-character hex string could be MD4, MD5, NTLM, LM, or RIPEMD-128. Here is how to disambiguate:

MD5 vs NTLM: Both are 32 hex chars. NTLM hashes are Windows domain hashes, typically extracted from a Domain Controller or SAM file. MD5 is used in Linux /etc/shadow (old), WordPress, and Joomla.
SHA-1 vs RIPEMD-160: Both 40 hex chars. SHA-1 is far more common. RIPEMD-160 appears in Bitcoin address hashing (combined with SHA-256).
CRC32 vs Adler32: Both 8 hex chars. CRC32 is more common in ZIP files and network protocols. Adler32 appears in zlib compression.

The Hash Identifier handles overlapping cases by scoring multiple factors: exact length match, regex pattern match, and a bonus for combined matching. The highest score is your best guess.

What the Tool Cannot Do

Hash identification is pattern-based, so there are limitations:

Salted hashes look identical to unsalted ones — the tool cannot detect if a salt was used.
Custom algorithms with no public pattern will not match any known type.
Encoded data (Base64, hex) may match multiple generic patterns — context matters.
Collisions: an MD5 hash and an NTLM hash can be identical in format. The tool cannot distinguish them without knowing the source.

Always combine tool output with contextual knowledge: Where did you find the hash? What system generated it? What format does the application expect?

Conclusion

Hash identification is a fundamental skill for security researchers, penetration testers, and CTF players. By analyzing length, prefix, and character set, you can narrow down 40+ hash types in seconds.

The Hash Identifier gives you an instant, client-side match with confidence scoring — no data leaves your machine, no terminal commands needed.

Try it with your own hashes:

Identify any hash:

Hash Identifier →

Published May 28, 2026 · Practical Guide · SecuriTool

How to Check If Your Email Is Protected with SPF, DKIM and DMARC

ReplikanteK — Sun, 24 May 2026 12:04:52 +0000

How to Check If Your Email Is Protected with SPF, DKIM and DMARC

May 24, 20268 min read

If you own a domain and use email, you need three DNS records to keep your messages out of spam folders and prevent impersonation: SPF, DKIM, and DMARC. Without them, anyone can send forged emails from your domain (phishing, spoofing).

This guide walks you through checking whether your domain has them configured correctly using the Email Security Checker from SecuriTool, and how to interpret each result.

✅ Open the checker in another tab while you read:

Email Security Checker →

What Are SPF, DKIM, and DMARC?

These three email authentication mechanisms work together. None is sufficient on its own:

Record	What It Does	What It Protects Against
SPF	Lists the servers authorized to send email for your domain	Anyone sending from an unauthorized IP
DKIM	Digitally signs emails with a public key in your DNS	Message tampering in transit
DMARC	Tells receivers what to do when SPF or DKIM fail (none/quarantine/reject)	Direct domain spoofing and phishing

Step 1: Open the Email Security Checker

Navigate to the Email Security Checker. You will see a single input field for a domain name.

Important: The entire analysis runs in your browser via DNS-over-HTTPS. No data is sent to any server — not your domain, not the results.

Step 2: Enter Your Domain

Type the domain you want to check (for example, example.com) and click "Check". The tool queries DNS records and displays results within seconds.

Step 3: Interpret the Results

SPF

A correct SPF record looks like this:

v=spf1 include:_spf.google.com ~all

What to look for:

✅ Pass: A valid SPF record exists. You will see the list of authorized servers.
⚠️ SoftFail or ~all: SPF exists but is not strict — unauthorized servers are marked as suspicious but not rejected.
❌ Not found: No SPF record. Your emails can be spoofed trivially.
❌ Error: Too many DNS lookups (exceeds 10). Many receivers will ignore the SPF entirely.

🔧 How to Fix SPF

For Google Workspace, add this TXT record to your DNS:

v=spf1 include:_spf.google.com ~all

For Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Once verified, change ~all to -all to reject unauthorized senders.

DKIM

DKIM requires two parts: a public key in your DNS (generated by your email provider) and signing enabled on your mail server.

What to look for:

✅ Valid: A DKIM key was found with correct format. The selector and key details are shown.
⚠️ Weak: The key uses RSA 1024-bit or less. Consider upgrading to 2048-bit.
❌ Not found: No DKIM record. Generate one from your email provider and add it to DNS.

🔧 How to Set Up DKIM

In Google Workspace: Admin → Apps → Gmail → Authenticate email → Generate new record. Copy the TXT record to your DNS.

In Microsoft 365: Admin portal → Exchange → Protection → DKIM → Enable and rotate keys.

DMARC

DMARC is the policy that decides what happens when SPF or DKIM fail. Without DMARC, attackers can spoof your domain even if you have SPF and DKIM.

A typical DMARC policy:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

What to look for:

✅ Pass: DMARC is configured with a policy. The tool displays the active policy.
⚠️ Monitoring (p=none): DMARC exists but enforces nothing. Useful for initial testing, but does not actively protect.
❌ Not found: No DMARC record. No spoofing protection.

Policy	Meaning	When to Use
`p=none`	Monitor only, no blocking	First few days to ensure no false positives
`p=quarantine`	Suspicious emails go to spam	Transition phase after monitoring
`p=reject`	Emails failing SPF/DKIM are rejected	Goal state. Full protection

🔧 How to Implement DMARC Gradually

Week 1: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — observe only
Week 2: Review DMARC reports (sent to the rua email). If clean, escalate to p=quarantine
Week 3: Move to p=reject — full spoofing protection

BIMI (Bonus)

BIMI displays your brand logo next to verified emails in Gmail and Apple Mail. The tool checks this too.

Requirements for BIMI:

DMARC set to p=reject or p=quarantine
Logo in SVG format hosted on your domain
Optional VMC (Verified Mark Certificate)

Complete Example

Here is what results look like for a well-configured domain:

📧 Email Security Report — example.com

╔════════════════════════════════════╗
║ SPF:  ✅ Pass                      ║
║       v=spf1 include:_spf.google.com ~all ║
╠════════════════════════════════════╣
║ DKIM: ✅ Valid (selector: google)  ║
║       RSA 2048 bits                ║
╠════════════════════════════════════╣
║ DMARC: ✅ Pass (p=reject)          ║
║       rua: mailto:dmarc@example.com║
╠════════════════════════════════════╣
║ BIMI: ✅ Logo found                ║
║       selectors: google,_domainkey ║
╚════════════════════════════════════╝
📊 Grade: A+

The overall Grade summarizes the state of all three mechanisms. An A or A+ means all three are properly configured.

FAQ

How often should I check my configuration?

At least once a month. Email providers change their servers (Google, Microsoft) and your records may become outdated. Also check after changing email providers or hosting.

Can I have SPF without DMARC?

Yes, but it is not recommended. DMARC is the only mechanism that tells the receiver what to do when SPF or DKIM fails. Without it, each server decides independently — and many will still deliver fraudulent email.

What does "too many DNS lookups" mean in SPF?

The standard allows a maximum of 10 DNS lookups per SPF check. Each include:, redirect=, or mx counts as one. If you exceed 10, servers may ignore your SPF entirely.

Does the checker store my domain?

No. All analysis runs in your browser via DNS-over-HTTPS. No data is sent to any server. Verify this by opening developer tools (F12 → Network tab) while running a check.

Conclusion

SPF, DKIM, and DMARC are the foundation of email security. Configuring them correctly protects your domain against spoofing, improves deliverability, and is a requirement for any organization using professional email.

Use the Email Security Checker to test your domain now — it takes under a minute and is completely private.

🔍 Check your domain now:

Email Security Checker →

Published May 24, 2026 · Practical Guide · SecuriTool

DEV Community: ReplikanteK

What Is a JWT and How to Inspect Its Security Claims

What Is a JWT and How to Inspect Its Security Claims

What Is a JWT?

Why Inspect JWT Security Claims?

Step-by-Step: Decode a JWT

Header Claims: What to Check

The alg claim

The kid claim

The jwk and jku claims

Payload Claims: What to Check

Missing expiration (exp)

Missing issuer/audience validation

Privilege claims

Common JWT Attack Patterns

Real-World Example

What the Tool Cannot Do

Conclusion

How to Identify Hash Types: A Step-by-Step Guide

How to Identify Hash Types: A Step-by-Step Guide

How to Identify Hash Types: A Step-by-Step Guide

How Hash Identification Works

Step 1: Paste the Hash

Step 2: Read the Results

Step 3: Identify by Length

Step 4: Identify by Prefix

Step 5: Read a Real-World Example

Quick Reference: Common Hash Patterns

When Lengths Overlap

What the Tool Cannot Do

Conclusion

How to Check If Your Email Is Protected with SPF, DKIM and DMARC

How to Check If Your Email Is Protected with SPF, DKIM and DMARC

How to Check If Your Email Is Protected with SPF, DKIM and DMARC

What Are SPF, DKIM, and DMARC?

Step 1: Open the Email Security Checker

Step 2: Enter Your Domain

Step 3: Interpret the Results

SPF

🔧 How to Fix SPF

DKIM

🔧 How to Set Up DKIM

DMARC

🔧 How to Implement DMARC Gradually

BIMI (Bonus)

Complete Example

FAQ

How often should I check my configuration?

Can I have SPF without DMARC?

What does "too many DNS lookups" mean in SPF?

Does the checker store my domain?

Conclusion

The `alg` claim

The `kid` claim

The `jwk` and `jku` claims

Missing expiration (`exp`)