Cryptography Basics for Testers

Why it matters

A product can lose every password, card number or session token while every feature "works": the values only need to be stored in a reversible encoding or with a fast, unsalted hash, or a forged webhook only needs to be accepted because nobody verified its signature. The OWASP Top 10 groups these cases under A04:2025 Cryptographic Failures, and functional testing does not find them, because the user's own journey succeeds.

A tester does not need the mathematics. A tester needs three things: to recognise the kind of value in front of them from its shape, to know which tool fits which purpose (encoding for transport, hashing for integrity and passwords, HMAC for proving the origin, encryption for confidentiality), and to ask the right questions: where is the key, who verifies, and what happens when it leaks?

Encoding, hashing and encryption are three different things

Encoding changes how data is represented, by a public rule with no secret in it. Base64 (RFC 4648) turns every 3 bytes into 4 characters from a 64-character alphabet and, when needed, pads the end with =; hex writes every byte as two digits. Its purpose is to carry bytes safely inside text, a URL or an HTTP header, as the Basic Authorization header in the lessons on HTTP headers and on authentication and authorization did. Whoever has the output has the input.

Hashing turns any input into a fixed-length fingerprint: 64 hex characters for SHA-256, 40 for SHA-1, 32 for MD5. The same input always gives the same hash, the input cannot be recovered from the hash, and changing one character changes the whole hash. Systems use it to check that a file is intact and to compare data without storing it. MD5 and SHA-1 must not be used where security depends on them: practical ways to create two different inputs with the same hash (a collision) have been published for both.

Encryption hides data so that it can only be recovered with a key. Symmetric encryption (AES, for example) uses the same key to encrypt and decrypt; asymmetric encryption (RSA and elliptic curves) uses a key pair, where what the public key encrypts only the private key can decrypt. TLS uses both: asymmetric to identify the server and agree keys, symmetric for the data itself. The question that separates the three is: can it be reversed, and who holds what is needed to reverse it?

Input: password123

Encoding    Base64       cGFzc3dvcmQxMjM=
                         anyone can decode it: no key, no secret
Hashing     SHA-256      ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
                         one way, fixed length, same input -> same output
            MD5 (legacy) 482c811da5d5b4bc6d497ffa98491e38
                         32 hex characters; not for anything security-related
HMAC        HMAC-SHA256  2b46560cfc07e738b1b40765b282308026cdd5b9d2aae58be8a347b1293a82e7
                         key: test-secret; only a key holder can compute or check it
Encryption  AES-256-GCM  <ciphertext + nonce>, different on every run
                         reversible only with the key

Try it: Base64 Decoder Try it: SHA-256 Generator Try it: MD5 Generator

HMAC and signatures: a hash with a key proves the origin

A hash alone detects a change but does not prove the origin: whoever edits a message can compute its new hash too. HMAC (RFC 2104) solves this by mixing a secret key into the calculation: HMAC-SHA256(key, message). Only a holder of the key can produce or check the right value, so the value proves two things at once: the message was not changed, and it came from someone who holds the secret. HMAC does not hide the message; it is not encryption.

You will meet it in webhook signatures (a header such as X-Signature-256), in JWTs signed with HS256 (which is HMAC-SHA256) and in signed links and cookies. A digital signature (RS256 or ES256, for example) does the same job with asymmetric keys: the private key signs and the public key verifies, so the verifier needs no secret. In both cases decoding a token is one thing and verifying its signature is another, as the JWT guide explains.

• Same body, correct signature: accepted. Change one character of the body and keep the signature: must be rejected.
• A signature computed with the wrong secret, or no signature header at all: both must be rejected. A server that accepts the request without the header is not verifying.
• Replaying an old, valid request: HMAC alone does not prevent it. Ask whether a timestamp is part of the signed material and whether old ones are rejected.
• Ask the developer how the two values are compared: the usual recommendation is a constant-time comparison, which takes the same time however many characters match, so response times reveal nothing about a guess. You cannot see it from outside.

Partner -> your server

POST /webhooks/payments HTTP/1.1
Host: shop.example.com
Content-Type: application/json
X-Signature-256: sha256=ff40b419851351c2ed7966278bc1d026ecbac717fbbbfebfb068715b3860c4d7

{"event":"order.paid","orderId":"ORD-1042","amount":"249.00"}

Check on your server: HMAC-SHA256(secret, raw body) == the value after "sha256="?
  yes -> process the event      no -> reject it (for example with 401)
Secret for this example: whsec_test_key. Change one byte of the body, or the secret,
and the computed value no longer matches.

Try it: HMAC Generator Try it: Webhook Signature Analyzer

Password hashing is a special case

Passwords are weak inputs: short, predictable and reused. A fast hash such as SHA-256 is therefore not enough, because an attacker who obtains the database can compute the hashes of billions of common passwords and compare. The answer has two parts: a random salt that differs per user, so two users who chose the same password have different stored values and precomputed tables are useless; and a function designed to be deliberately slow, and in Argon2id and scrypt also memory-hungry: a delay one login can afford and a billion guesses cannot.

The OWASP Password Storage cheat sheet recommends Argon2id first, then scrypt, bcrypt for legacy systems, and PBKDF2 where FIPS-140 compliance (a US government standard for cryptographic modules) is required. These algorithms generate the salt themselves and store it inside the value, next to the algorithm name and its parameters; the salt is not a secret, its only job is to make every stored value unique. So you can recognise these values by their shape, as in the example.

• Create two accounts with the same password: the stored values must differ (a salt per user).
• Forgot password: a reset link must arrive, never the current password. A system that can send it stores it in a reversible form.
• With bcrypt, remember that it ignores everything after 72 bytes: set an 80-character password, then log in with the last character changed. If login succeeds, ask about the length limit.
• Look at the value, not the name: a column called password_hash can hold Base64 or MD5.

Two users, both chose password123

Unsalted SHA-256 (defect): identical values, and easy to look up in precomputed tables
  user A  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
  user B  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

Argon2id (accepted): algorithm, parameters, random salt and hash; different per user
  user A  $argon2id$v=19$m=19456,t=2,p=1$<salt A>$<hash A>
  user B  $argon2id$v=19$m=19456,t=2,p=1$<salt B>$<hash B>

bcrypt (accepted): $2b$<cost>$<22-character salt><31-character hash>, 60 characters

TLS and keys: where the tools meet the system

The lesson on HTTP and HTTPS explained the handshake, certificates and the chain of trust. Seen from this lesson, TLS (RFC 8446 for version 1.3) is the most common place where these tools work together: a certificate and a digital signature to identify the server, asymmetric cryptography to agree keys, hashes and HMAC to derive those keys and confirm the handshake, then symmetric encryption with an integrity check on every byte that passes. Every password, token and card number sent over plain HTTP travels without any of these protections.

• Accepted versions: TLS 1.2 and 1.3 only; older versions and all of SSL are deprecated. Check this on every environment, not only production. The API Endpoint Tester reports the TLS and HSTS of a public endpoint; listing every version a server still accepts needs a TLS scanner, such as nmap --script ssl-enum-ciphers -p 443 <host>, run only on hosts you have permission to test.
• Every entry point: the API, the web app, the mobile app, the webhook your server sends to a partner and the internal calls between services, not only the home page.
• Test clients verify certificates the way real users do; switching verification off "for now" is a defect in the test setup itself.
• Keys and secrets: a key embedded in a front-end bundle or a mobile app is effectively public; a secret produced with Math.random() is not random enough; and ask how a key is rotated when it leaks.
• What does "encrypted at rest" mean here? Ask who holds the key: if the application server can decrypt everything, so can anyone who compromises it.

Try it: API Endpoint Tester

Worked example: reviewing a payment and webhook feature

You are testing a new feature: a customer creates an account, saves a card, and the payment partner notifies your server of each payment through a webhook. During the design and data review you notice four values:

• users.password holds cGFzc3dvcmQxMjM=: Base64, so a plain password for anyone who reads the database. Defect; attach the decoded value from the test environment, never a real user's password.
• cards.pan_masked shows **** 4242, but the /profile response carries a cardRef in Base64 that decodes to the full card number. A sensitive data exposure defect whose root cause is mistaking encoding for encryption.
• The webhook carries X-Signature-256, yet the same request without the header is accepted with 200. The server is not verifying; anyone who knows the URL can announce "payment received". Defect.
• A TLS check on api-staging shows that TLS 1.0 is accepted. A finding for the platform team, with a question: is production configured the same way?

Frequently asked questions

References

• OWASP Cheat Sheet Series: Cryptographic StorageOWASP FoundationWhich algorithms and key lengths to use for data at rest, and how to manage keys and randomness.
• OWASP Cheat Sheet Series: Password StorageOWASP FoundationHow to store passwords: Argon2id, scrypt or bcrypt with salts — never MD5, SHA-1 or unsalted hashes.
• RFC 2104: HMAC: Keyed-Hashing for Message AuthenticationIETF · 1997The HMAC construction: how a secret key and a hash function produce a message authentication code.
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018The TLS 1.3 handshake and record protocol that protect HTTPS traffic.