Security Lab

Common Workflows

• Generating a strong password or passphrase, then immediately checking its composition and entropy with the Password Analyzer before using it anywhere real.
• Building a JWT with the JWT Generator, decoding it with the JWT Inspector to confirm the claims are exactly as intended, then testing an edge case (an expired or tampered token) with the JWT Claims Editor.
• Computing a file or payload's hash with the Hash Generator to verify integrity, or an HMAC with the HMAC Generator when the value also needs to prove it came from a party holding a shared secret.
• Generating a UUID, ULID, or NanoID for a new resource identifier, choosing between them based on whether sort-order or compactness actually matters for that specific use case.
• Encrypting a test payload with the Encryption Studio to confirm a symmetric or asymmetric scheme behaves as expected before wiring it into real application code.

Tool Selection Strategy

• Start from the question you're actually answering, not the tool name: 'does this need to be recovered later' points to encryption; 'does this only need to be verified, never recovered' points to hashing; 'does this need to prove who sent it, not just that it's unmodified' points to HMAC or a digital signature rather than a plain hash.
• For password-adjacent work specifically, always reach for the dedicated slow, memory-hard functions (Bcrypt Hasher, and Argon2 via the Encryption Studio's key-derivation support) rather than the general-purpose Hash Generator — a fast hash is the wrong tool for anything an attacker might try to brute-force offline.
• When choosing between UUID, ULID, and NanoID for a new identifier, decide first whether database insert-order matters (favoring ULID) or compactness for a public URL matters (favoring NanoID) — defaulting to UUID without checking either is the most common unexamined choice in this category.

Common Mistakes

• Encrypting a password for storage instead of hashing it — encryption is reversible by design, which is exactly the property you don't want for a stored credential.
• Putting sensitive data directly in a JWT payload, forgetting that the payload is only base64url-encoded, not encrypted, and fully readable by anyone who has the token.
• Using a fast, general-purpose hash function (like plain SHA-256) for password storage instead of a dedicated slow, memory-hard function — speed is the wrong property to optimize for here.
• Reusing the same signing secret or key across multiple environments or services, so that a single leak compromises everything relying on that key at once.

Standards Landscape

• NIST SP 800-63B governs modern digital-identity and password-composition guidance, including the now-standard advice against mandatory periodic password rotation.
• RFC 7519 (JWT), RFC 7515 (JWS), and RFC 7516 (JWE) define the token formats this category's JWT tools implement.
• RFC 9106 defines Argon2, the current recommended password-hashing algorithm; FIPS 197 defines AES, the standard symmetric cipher this category's encryption tools use.

Glossary

Hashing

A one-way transformation of data into a fixed-size digest; the same input always produces the same output, but the output cannot be reversed back into the input.

Encryption

A reversible transformation of data that requires a key to decrypt back to the original — used for confidentiality, unlike hashing.

HMAC

A keyed hash construction that proves both integrity and that the sender held a specific shared secret, distinct from a plain unkeyed hash.

Salt

Random data mixed into a password before hashing, ensuring identical passwords produce different hashes and defeating precomputed lookup-table attacks.

Memory-hard function

A hashing algorithm (like Argon2 or scrypt) deliberately designed to require significant memory, not just CPU time, to compute — raising the cost of parallel cracking hardware.

JWT (JSON Web Token)

A compact, signed token format for representing claims between two parties, commonly used for stateless session authentication.

Non-repudiation

The property that a specific party, and only that party, could have produced a given signature — provided by asymmetric digital signatures, not by symmetric HMACs.

Troubleshooting

• If a hashed password never matches on verification, check whether the salt is being stored and reused correctly — a mismatched or regenerated salt produces a different hash even for the identical password.
• If a JWT fails signature verification unexpectedly, confirm both sides are using the exact same algorithm and secret/key — a token signed with HS256 will never verify against an RS256 configuration, regardless of whether the claims are otherwise correct.
• If an encrypted value can't be decrypted, verify the exact key, initialization vector, and cipher mode all match between encryption and decryption — a single mismatched parameter produces garbage output, not a clear error, in many implementations.

References

Related Categories

Other categories whose tools share a Developer Hub with Security Lab: