What cryptography can and cannot do

The OWASP Top 10:2025 ranks cryptographic failures fourth among the risks to web applications, with 32 weakness types and 1,665,348 occurrences in its data. The first weaknesses it names are a broken or risky algorithm, too little entropy and predictable random numbers: choices made in application code, where a tool was picked that does not give the guarantee the feature needed.

Cryptography gives four precise guarantees, each from its own kind of tool, and nothing beyond them. Here you match each guarantee to the primitivecryptographic primitive: A basic building block with one precise job, such as a hash function, a MAC, a cipher or a signature scheme. Protocols such as TLS combine several primitives. that provides it, see in a program why Base64 and a plain hash protect nothing from an attacker, turn a feature into a four-line threat model, choose a library, and meet the problems that no cipher fixes, so that you know when the answer is an access check rather than more encryption.

Four guarantees, and the tool that gives each

Your shop’s server receives this from its payment provider: {"order": 4471, "amount": 500}. Before it marks the order paid, it needs four answers, and each one is a different guarantee with a different tool behind it:

NIST’s key-management recommendation, SP 800-57 Part 1, defines the same services: confidentiality keeps information from unauthorised parties, data integrity means no unauthorised change since the data was created, sent or stored, and source authentication gives assurance about who created or sent it. It adds two warnings worth keeping. One mechanism may provide several services but never all of them, and whether a signature really commits its signer is in the end a legal decision, not a mathematical one.

A MACmessage authentication code (MAC): A function of a secret key and a message whose output, the tag, only holders of the key can compute. A receiver with the key recomputes the tag to check that the message is unchanged and came from a key holder; HMAC and KMAC are MACs. More in “HMAC and constant-time verification”, such as HMAC from RFC 2104, mixes a secret key into a hash, and that key is the whole difference. Step through one order update sent three ways and watch which design stops a person on the network path:

The program below runs those three designs with real functions. It flips one bit on the way, which turns 500 into 501, then swaps in a forged order with whatever someone without the key can compute. Press Run, then try your own forged amount, or a guessed key that is closer to the real one:

"""One webhook message protected three ways, and what someone on the network path can do."""
import base64
import hashlib
import hmac

# A fixed demo key, so the output repeats. Real keys come from a secrets store.
KEY = b"key-for-demo-only-not-a-real-key"
MESSAGE = b'{"order": 4471, "amount": 500}'
CHANGED = b'{"order": 4471, "amount": 5000}'


def tag(key, message):
    return hmac.new(key, message, hashlib.sha256).digest()


# What the receiving server checks in each design. In all three the message
# itself travels as it is, so anyone on the path can read it.
def accepts_base64(wire):
    return True  # whatever decodes is taken as the message


def accepts_digest(message, digest):
    return hashlib.sha256(message).digest() == digest


def accepts_tag(message, received_tag):
    return hmac.compare_digest(tag(KEY, message), received_tag)


flipped = MESSAGE[:-2] + bytes([MESSAGE[-2] ^ 1]) + MESSAGE[-1:]  # 500 -> 501
wire = base64.b64encode(MESSAGE)
print("Message:      ", MESSAGE.decode())
print("Base64 form:  ", wire.decode())
print("Decoded again:", base64.b64decode(wire).decode())
print("SHA-256:      ", hashlib.sha256(MESSAGE).hexdigest()[:24], "...")
print("HMAC-SHA-256: ", tag(KEY, MESSAGE).hex()[:24], "...")
print()

# Someone on the path flips one bit, or sends CHANGED with whatever they can compute.
rows = [
    ("Base64", None, accepts_base64(base64.b64encode(CHANGED))),
    ("SHA-256 digest",
     not accepts_digest(flipped, hashlib.sha256(MESSAGE).digest()),
     accepts_digest(CHANGED, hashlib.sha256(CHANGED).digest())),
    ("HMAC-SHA-256 tag",
     not accepts_tag(flipped, tag(KEY, MESSAGE)),
     accepts_tag(CHANGED, tag(b"a guess, not the key", CHANGED))),
]
print(f"{'Protection':<18}{'Readable':<10}{'Bit flip caught':<17}Forged change accepted")
for name, caught, forged in rows:
    flip = "no check" if caught is None else ("yes" if caught else "no")
    print(f"{name:<18}{'yes':<10}{flip:<17}{'yes' if forged else 'no'}")

Message:       {"order": 4471, "amount": 500}
Base64 form:   eyJvcmRlciI6IDQ0NzEsICJhbW91bnQiOiA1MDB9
Decoded again: {"order": 4471, "amount": 500}
SHA-256:       276917d7713fc8190603a982 ...
HMAC-SHA-256:  d1e5e0defa35bb038d523328 ...

Protection        Readable  Bit flip caught  Forged change accepted
Base64            yes       no check         yes
SHA-256 digest    yes       yes              yes
HMAC-SHA-256 tag  yes       yes              no

Only the HMAC tag rejected the forged order, and all three left the amount readable. Here are the same checks in JavaScript with Web Crypto, as Node.js 24.21.0 ran them; the table is identical:

// One webhook message protected three ways, and what someone on the network path can do.
// The same checks as properties.py, with Web Crypto (globalThis.crypto.subtle).
const { subtle } = globalThis.crypto;
const bytes = (text) => new TextEncoder().encode(text);
const hex = (buffer) => Array.from(new Uint8Array(buffer), (b) => b.toString(16).padStart(2, '0')).join('');

// A fixed demo key, so the output repeats. Real keys come from a secrets store.
const KEY = bytes('key-for-demo-only-not-a-real-key');
const MESSAGE = bytes('{"order": 4471, "amount": 500}');
const CHANGED = bytes('{"order": 4471, "amount": 5000}');

const hmacKey = (raw) => subtle.importKey('raw', raw, { name: 'HMAC', hash: 'SHA-256' }, false, ['sign', 'verify']);
const sha256 = (data) => subtle.digest('SHA-256', data);
const tag = async (raw, message) => subtle.sign('HMAC', await hmacKey(raw), message);

// What the receiving server checks in each design. In all three the message
// itself travels as it is, so anyone on the path can read it.
const acceptsBase64 = (wire) => true; // whatever decodes is taken as the message
const acceptsDigest = async (message, digest) => hex(await sha256(message)) === hex(digest);
const acceptsTag = async (message, receivedTag) => subtle.verify('HMAC', await hmacKey(KEY), receivedTag, message);

const flipped = MESSAGE.slice();
flipped[flipped.length - 2] ^= 1; // 500 -> 501
const wire = btoa(String.fromCharCode(...MESSAGE));
console.log('Message:      ', new TextDecoder().decode(MESSAGE));
console.log('Base64 form:  ', wire);
console.log('Decoded again:', atob(wire));
console.log('SHA-256:      ', hex(await sha256(MESSAGE)).slice(0, 24), '...');
console.log('HMAC-SHA-256: ', hex(await tag(KEY, MESSAGE)).slice(0, 24), '...');
console.log();

// Someone on the path flips one bit, or sends CHANGED with whatever they can compute.
const rows = [
  ['Base64', null, acceptsBase64(btoa(String.fromCharCode(...CHANGED)))],
  ['SHA-256 digest', !(await acceptsDigest(flipped, await sha256(MESSAGE))), await acceptsDigest(CHANGED, await sha256(CHANGED))],
  ['HMAC-SHA-256 tag', !(await acceptsTag(flipped, await tag(KEY, MESSAGE))), await acceptsTag(CHANGED, await tag(bytes('a guess, not the key'), CHANGED))],
];
console.log(`${'Protection'.padEnd(18)}${'Readable'.padEnd(10)}${'Bit flip caught'.padEnd(17)}Forged change accepted`);
for (const [name, caught, forged] of rows) {
  const flip = caught === null ? 'no check' : caught ? 'yes' : 'no';
  console.log(`${name.padEnd(18)}${'yes'.padEnd(10)}${flip.padEnd(17)}${forged ? 'yes' : 'no'}`);
}

Message:       {"order": 4471, "amount": 500}
Base64 form:   eyJvcmRlciI6IDQ0NzEsICJhbW91bnQiOiA1MDB9
Decoded again: {"order": 4471, "amount": 500}
SHA-256:       276917d7713fc8190603a982 ...
HMAC-SHA-256:  d1e5e0defa35bb038d523328 ...

Protection        Readable  Bit flip caught  Forged change accepted
Base64            yes       no check         yes
SHA-256 digest    yes       yes              yes
HMAC-SHA-256 tag  yes       yes              no

Encoding hides nothing, and neither does a secret design

A mobile team wants the app’s discount codes out of plain sight, so it stores them Base64-encoded and reversed. The app ships to a million phones, and every copy carries the code that undoes the trick. Nobody needs a key, because there is none: the first person to unpack the app has every code.

In 1883 Auguste Kerckhoffs listed six requirements for a cipher system, and the second has outlived the telegraph: the details of the system may become known without harm to the people using it, so its security must rest on the key alone. This is Kerckhoffs’s principleKerckhoffs's principle: The rule that a cryptosystem must stay secure even when everything about it except the key is public, so that its security rests on the key alone.. Today it reads: assume that an attacker has your source code, your binaries and the algorithm’s specification, and design so that the only thing they lack is the key. There are good reasons for it. Designs leak through shipped apps, public repositories and former staff. A leaked key can be replaced in minutes, while a leaked design cannot. And a published algorithm has been attacked by many people before you trust it.

Every transformation that needs no key fails that test:

The first row of the program’s table above shows this for Base64: decoded again, the order reads exactly as it was sent.

A threat model in four lines

A shop emails a link to reset a password: https://shop.example/reset?token=…. Before choosing any tool, write down what you are defending against. Four lines are enough for most features:

1. What we protect: the account the link opens.
2. Who might attack, and from where: someone who sees the link in a log or a forwarded email, someone who tries tokens at random, someone who gets a copy of the database.
3. What they can see, change, replay or guess: they can read the address in a log, use a link they saw again, guess tokens, and read the stored copy of every token.
4. What must still hold: a token cannot be guessed, works once, expires soon, belongs to one account, and is stored only as a hash, so a database copy reveals no working link.

Each ability in line 3 points at what the design needs. Reading calls for confidentiality, and changing for integrity with authenticity. Guessing calls for enough randomness: OWASP’s verification standard, ASVS 5.0, asks for at least 128 bits from a cryptographically secure generator for any value that must not be guessed (requirement 11.5.1). Replayreplay: Sending a captured, valid message again. A MAC or a signature still verifies on the copy, so a design needs its own freshness check, such as a timestamp, a nonce or a record of what was accepted. is the one that tags and signatures do not stop on their own, because a resent message verifies exactly like the original, so it needs its own rule, such as a timestamp, a single-use token or a record of what was already accepted. Say what is out of scope too: a person who controls the user’s mailbox can reset the password whatever the token, and that is a job for a second factor, not for the link.

Answer the threat model’s questions for your own data in the table below. It rules out the tools that cannot give what you need, and says why:

In short: data that must stay secret needs encryption, and an authenticated cipher also proves it unchanged; a message checked by a party that shares your key needs a MAC; one that anyone or a third party must check needs a signature; passwords need a password hash; and replay needs its own check whatever you pick.

Reach for the highest-level tool in a maintained library

The README of crypto-js, a JavaScript library that many projects still install, says that its active development has been discontinued and that it is no longer maintained, and it points users to the native crypto module of Node.js and browsers instead. Every package you add carries its maintainers’ future with it: a library nobody maintains gets no fixes for the next weakness found in it.

Two rules keep most code out of trouble. Use the platform’s own cryptography where it exists: Web Crypto in browsers and Node.js, node:crypto, Python’s hashlib, hmac and secrets with the cryptography package for the rest, Java’s cryptography architecture, Go’s crypto packages. ASVS 5.0 asks for industry-validated implementations of every operation (requirement 11.2.1). And use the highest-level operation that fits:

The W3C specification even names its low-level interface SubtleCrypto, to signal that its algorithms have subtle usage requirements. Before you add a package, ask the platform what it already offers. This program does that by trying, which is how portable code should detect an algorithm:

// Which algorithms does this runtime's Web Crypto offer? Feature-detect by trying,
// instead of assuming: engines differ, and old algorithms are left out on purpose.
const { subtle } = globalThis.crypto;
const publicExponent = new Uint8Array([1, 0, 1]); // 65537, big-endian

const keys = [
  ['AES-GCM, 256-bit key', { name: 'AES-GCM', length: 256 }, ['encrypt', 'decrypt']],
  ['HMAC with SHA-256', { name: 'HMAC', hash: 'SHA-256' }, ['sign', 'verify']],
  ['Ed25519 signatures', { name: 'Ed25519' }, ['sign', 'verify']],
  ['ECDSA on P-256', { name: 'ECDSA', namedCurve: 'P-256' }, ['sign', 'verify']],
  ['X25519 key agreement', { name: 'X25519' }, ['deriveBits']],
  ['RSA-OAEP, 3072-bit', { name: 'RSA-OAEP', modulusLength: 3072, publicExponent, hash: 'SHA-256' }, ['encrypt', 'decrypt']],
  ['DES-CBC', { name: 'DES-CBC', length: 64 }, ['encrypt', 'decrypt']],
  ['AES-ECB', { name: 'AES-ECB', length: 128 }, ['encrypt', 'decrypt']],
];
const digests = ['SHA-256', 'SHA-512', 'SHA-1', 'MD5'];

const result = async (work) => {
  try {
    await work();
    return 'yes';
  } catch (err) {
    return `no (${err.name})`;
  }
};

console.log('Key generation');
for (const [label, algorithm, usages] of keys) {
  console.log(`  ${label.padEnd(24)}${await result(() => subtle.generateKey(algorithm, false, usages))}`);
}
console.log('Digests');
for (const name of digests) {
  console.log(`  ${name.padEnd(24)}${await result(() => subtle.digest(name, new Uint8Array(1)))}`);
}

Key generation
  AES-GCM, 256-bit key    yes
  HMAC with SHA-256       yes
  Ed25519 signatures      yes
  ECDSA on P-256          yes
  X25519 key agreement    yes
  RSA-OAEP, 3072-bit      yes
  DES-CBC                 no (NotSupportedError)
  AES-ECB                 no (NotSupportedError)
Digests
  SHA-256                 yes
  SHA-512                 yes
  SHA-1                   yes
  MD5                     no (NotSupportedError)

Node.js 24.21.0 offers every modern tool in the list and refuses DES, AES in ECB mode and MD5, none of which the Web Cryptography specification defines at all. Code that asks for one of them is a sign of an old design.

“FIPS validated” is a different question again. It means that NIST’s Cryptographic Module Validation Program accepted a lab’s test of the module against FIPS 140, so the module has a validation certificate number; modules validated under the older FIPS 140-2 now sit on the program’s historical list, kept for systems already in use. A validated module can still be used the wrong way, so compliance and security are related questions, not the same one.

What no cipher can fix

Asha is signed in to an invoicing app over TLS 1.3, with a session token whose HMAC tag the server checks on every request. Her invoice is number 1042. She changes the address to 1043 and gets Ben’s invoice. Step through the request:

Every cryptographic check passed: the connection was encrypted and the token was genuine. What failed is a rule, and OWASP ranks it first in the Top 10:2025 as broken access control: access control enforces a policy so that users cannot act outside their permissions, and this handler never asked whether invoice 1043 was Asha’s. NIST draws the same line in SP 800-57: authorisation, the permission to perform an activity, is a security service that cryptography often supports rather than provides. The program below runs both handlers against the same three requests, and the last column is the test that fails on the weak handler and passes on the fix. Run it, then add a third invoice for Ben and ask for it with Asha’s token:

"""Every cryptographic check passes, and one handler still shows the wrong person an invoice."""
import hashlib
import hmac

# A fixed demo key, so the output repeats. Real keys come from a secrets store.
SESSION_KEY = b"session-key-for-this-demo-only!!"
INVOICES = {1042: {"owner": "asha", "total": 1200}, 1043: {"owner": "ben", "total": 87000}}


def issue_session(user):
    """A toy session token: the user's name and an HMAC tag (real ones also expire)."""
    tag = hmac.new(SESSION_KEY, user.encode(), hashlib.sha256).hexdigest()
    return f"{user}.{tag}"


def verify_session(token):
    """The user a session token names, or None when its tag does not match."""
    user, _, tag = token.partition(".")
    expected = hmac.new(SESSION_KEY, user.encode(), hashlib.sha256).hexdigest()
    return user if hmac.compare_digest(expected.encode(), tag.encode()) else None


def get_invoice_weak(token, invoice_id):
    user = verify_session(token)
    if user is None:
        return 401
    return 200 if invoice_id in INVOICES else 404


def get_invoice_fixed(token, invoice_id):
    user = verify_session(token)
    if user is None:
        return 401
    invoice = INVOICES.get(invoice_id)
    if invoice is None or invoice["owner"] != user:
        return 404  # the same answer as "no such invoice": nothing to probe
    return 200


asha = issue_session("asha")
forged = "ben." + "0" * 64
print("Asha's session token:", asha[:20] + "...")
print()
print(f"{'Handler':<8}{'Asha: 1042':<12}{'Asha: 1043':<12}{'Forged token':<14}Result")
for name, handler in [("weak", get_invoice_weak), ("fixed", get_invoice_fixed)]:
    own, other, fake = handler(asha, 1042), handler(asha, 1043), handler(forged, 1043)
    result = "PASS" if (own, other, fake) == (200, 404, 401) else "FAIL: Asha reads Ben's invoice"
    print(f"{name:<8}{own:<12}{other:<12}{fake:<14}{result}")

Asha's session token: asha.b61ad51fe0929e6...

Handler Asha: 1042  Asha: 1043  Forged token  Result
weak    200         200         401           FAIL: Asha reads Ben's invoice
fixed   200         404         401           PASS

The forged token got 401 from both handlers, so the cryptography worked in both; only the ownership check separates them.

Problems of this kind need something other than cryptography:

• Missing authorisation checks, as above: every request needs a rule about who may do what.
• Leaked or hard-coded keys: encryption is only as secret as its key, and a key in a repository is public.
• A compromised device: malware on a phone or a laptop reads data before it is encrypted and after it is decrypted.
• A person tricked into the wrong action: a phishing page that the user signs in to gets a perfectly valid session.
• Copies outside the protected path: logs, caches and backups that hold the plaintext. OWASP’s guidance on cryptographic failures warns about caches that keep sensitive responses.

Practise: make the webhook check a real one

Write the server side of the third design: a function that accepts a webhook only when its HMAC-SHA-256 tag is right. The sample tests start with test case 2 of RFC 4231, the official HMAC-SHA-256 vector, then try a changed body, a tag made with another key, a plain digest of a forged body, a missing signature and signatures that are not hex. The starter code is the second design, a digest check, and the forged-digest test shows why it is not enough:

import hashlib


def verify(body, signature, key):
    """True when signature is the hex HMAC-SHA-256 tag of body under key, else False."""
    # This checks a plain SHA-256 digest, which anyone can compute for any body.
    # Replace it with an HMAC-SHA-256 check under key, compared in constant time.
    return hashlib.sha256(body).hexdigest() == signature

import hashlib
import hmac

from webhook import verify

KEY = b"webhook-key-for-the-sample-tests"
BODY = b'{"order": 4471, "amount": 500}'


def tag_of(body, key=KEY):
    return hmac.new(key, body, hashlib.sha256).hexdigest()


def test_rfc_4231_test_case_2():
    """the official HMAC-SHA-256 vector is accepted"""
    tag = "5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843"
    assert verify(b"what do ya want for nothing?", tag, b"Jefe") is True


def test_right_tag_accepted_in_either_case():
    """the right tag is accepted, in lower-case and upper-case hex"""
    assert verify(BODY, tag_of(BODY), KEY) is True
    assert verify(BODY, tag_of(BODY).upper(), KEY) is True


def test_changed_body_rejected():
    """a body changed after it was tagged is rejected"""
    changed = b'{"order": 4471, "amount": 5000}'
    assert verify(changed, tag_of(BODY), KEY) is False


def test_plain_digest_rejected():
    """a SHA-256 digest of the body, which anyone can compute, is rejected"""
    changed = b'{"order": 4471, "amount": 5000}'
    assert verify(changed, hashlib.sha256(changed).hexdigest(), KEY) is False


def test_other_key_rejected():
    """a tag made with another key is rejected"""
    assert verify(BODY, tag_of(BODY, b"some-other-key"), KEY) is False


def test_missing_signature_rejected():
    """a request without the signature header (None) gives False, without an exception"""
    assert verify(BODY, None, KEY) is False


def test_malformed_signatures_rejected():
    """signatures that are not 64 hex characters give False, without an exception"""
    for bad in ["", "abc", "zz" * 32, tag_of(BODY)[:-1], tag_of(BODY) + "00", "é" * 64]:
        assert verify(BODY, bad, KEY) is False, f"{bad!r} should be rejected"

Finish with a mixed set on all five ideas: it opens with the one you are weakest on, climbs a level each time you answer well, and asks again at the end whatever you missed:

Interview questions

Warm-up (fresher to mid level): what is the difference between encoding, hashing and encryption, and which of them needs a key?

Encoding, such as Base64 or hex, rewrites bytes in another alphabet so that they survive a text channel; it needs no key, anyone can reverse it, and it protects nothing. A hash such as SHA-256 maps any input to a fixed-size digest that cannot be turned back into the input; it needs no key either, so it detects accidental changes, but anyone can compute the digest of a forged message. Encryption needs a key: without it the ciphertext reveals nothing, and an authenticated cipher such as AES-GCM also detects any change. Add a key to a hash and you get a MAC such as HMAC, which proves that a key holder sent the message unchanged without hiding it. So the quick test is the key: no key, no protection against an attacker.

Key takeaways

• Cryptography gives four guarantees: confidentiality, integrity, authenticity and non-repudiation, each from its own tool, and a MAC is not a signature, because both sides hold its key.
• Base64, hex, compression and obfuscation need no key, so by Kerckhoffs’s principle they hide nothing from someone who knows the design.
• A four-line threat model (what you protect, who attacks from where, what they can see, change, replay or guess, and what must hold) decides the tool, and replay always needs its own check.
• Prefer the platform’s maintained cryptography and its highest-level operation: an authenticated cipher, a password hash, TLS, HPKE, a secure random generator.
• Authorisation, leaked keys, compromised devices and phishing are not cryptographic problems, and encrypting more does not fix them.