Security basics: passwords, hashes, HMAC, and JWTs

Security topics often sound intimidating because they’re taught with jargon first. In real life, most people need a smaller set of practical truths:

• How do I create passwords that won’t get guessed?
• What does hashing actually mean?
• When do I use HMAC instead of a hash?
• Why do apps store bcrypt strings instead of “encrypted passwords”?
• How do I inspect a JWT safely without accidentally trusting it?

This article answers those questions and links to free browser-based tools you can use to experiment. Everything here is educational; production systems should follow your organization’s security standards and threat model.

1) Passwords: length and randomness beat “clever” complexity

A strong password is typically long and random. Humans are bad at randomness, so “creative” passwords often contain patterns: keyboard walks, substitutions, repeated words, or predictable suffixes.

Practical guidance:

• Use a password manager if possible (unique password per site).
• Prefer long random passwords over short complex ones.
• Exclude ambiguous characters if you need to read/type the password manually.
• Enable multi-factor authentication when available.

2) Hashing: a one-way fingerprint (not reversible)

A hash function takes input data and produces a fixed-length output. Good cryptographic hashes are designed so that:

• It’s fast to compute the hash from the input.
• It’s extremely hard to find a different input that produces the same output.
• It’s not feasible to “reverse” the hash back into the original input.

Hashing is commonly used for integrity checks (did this file change?), identifiers, and safe comparisons (store the hash, compare hashes).

3) Hash vs encryption (a common misunderstanding)

Encryption is two-way: you encrypt and later decrypt with a key. Hashing is one-way. If you need to store passwords, you generally should not decrypt them at all—your system should verify a password by hashing the user’s input and comparing it to a stored hash.

4) HMAC: authenticity with a secret key

An HMAC (Hash-based Message Authentication Code) combines a message and a secret key to produce a signature. If two parties share a secret, they can use HMAC to prove a message hasn’t been modified in transit and came from someone who knows the secret.

Important: HMAC does not hide the message contents. It provides authenticity and integrity, not confidentiality.

5) Bcrypt: password storage done the “slow” way on purpose

If cryptographic hashes are designed to be fast, why is bcrypt popular for password storage? Because for passwords, fast is dangerous. Attackers can try billions of guesses per second against fast hashes. Bcrypt is intentionally slow and includes a salt and cost factor to make guessing expensive.

What to know when you see bcrypt in the real world:

• The stored bcrypt value typically includes the salt and cost parameters.
• You store the full bcrypt string; verification uses that string to recompute and compare.
• Higher cost means slower verification (more resistance to brute force) but more server CPU.

6) JWTs: decode to inspect, verify to trust

A JWT (JSON Web Token) contains three parts: header, payload (claims), and signature. It’s commonly used for authentication and authorization in web systems.

Decoding a JWT simply means base64-decoding those parts so you can read the JSON. That is helpful for debugging. But decoding alone does not prove the token is legitimate. Trust requires:

• Verifying the signature against the correct key.
• Validating issuer/audience and checking expiration timestamps.
• Rejecting unsafe algorithms and configuration mistakes.

A practical debugging workflow (safe and repeatable)

1. Generate or paste a password into a strength checker to see how length changes strength.
2. Hash a sample string with SHA‑256 and note that the same input always yields the same hash.
3. Create an HMAC for the same message using two different secrets and see how the signature changes.
4. Decode a JWT and look at claims like exp (expiration) and iss (issuer).

Using “toy” inputs like this is a great way to learn without risking real secrets.

Tools to try

Secure context note (why HTTPS matters)

Some browser APIs (especially cryptography and clipboard features) require a secure context (HTTPS or localhost). On Cloudflare Pages, your site is served over HTTPS, so these features work normally. If you test tools via plain HTTP on a remote device, your browser may disable them.

For sourcing and corrections standards, see the Editorial & Accuracy Policy.