OWASP A02
Testing for Cryptographic Failures
Most cryptographic findings are not broken algorithms. They are correct algorithms used wrongly, keys stored badly, or sensitive data that was never encrypted because nobody classified it as sensitive.
- Covers transport, storage and token signing together
- Key management reviewed, not just cipher suites
- Findings framed against PCI-DSS and HIPAA requirements
What cryptographic failures looks like in a real application
A platform stores customer identity documents in an object storage bucket with server-side encryption enabled, and the team reports that documents are encrypted at rest. They are — with a key the storage service manages and applies automatically to any request that can reach the object. The encryption satisfies a compliance checkbox and prevents nothing, because the threat was never the physical disk.
Cryptographic failures usually look like this. The primitive is fine. The way it was deployed does not address the risk anyone was worried about.
The cryptographic failures variants we test for
- Transport weaknesses — obsolete protocol versions, weak cipher suites, missing HSTS, mixed content and certificate validation gaps
- Password storage using fast hashes such as MD5, SHA-1 or unsalted SHA-256 instead of bcrypt, scrypt or Argon2
- Token signing flaws — unverified JWT signatures, algorithm confusion, none accepted, and secrets weak enough to brute force offline
- Encryption mode misuse such as ECB, static or reused initialisation vectors, and unauthenticated modes where integrity matters
- Predictable randomness in reset tokens, session identifiers, invitation links and one-time codes
- Key and secret handling — keys in source control, in client bundles, in environment dumps or shared across environments with no rotation path
- Sensitive data never encrypted because it was not classified, most often in logs, caches, analytics pipelines, backups and support tooling
- Reversible storage of data that should be hashed, and hashing of data that needs to be recoverable
How we test for cryptographic failures
Transport configuration is largely tooling work and we treat it that way. The manual effort goes where judgement is needed: what data your application holds, how it is classified, where it travels, and whether the protection applied at each stage matches the threat.
We trace a sensitive field from submission to storage and then outward, into logs, message queues, analytics, exports, backups and third-party services. Sensitive data reaching an unexpected destination in cleartext is one of the more common serious findings, and it is only visible if somebody follows the data rather than scanning the endpoint.
For tokens we attempt offline attacks against captured values, test signature verification directly, and check whether the server accepts algorithms it should reject.
Why scanners miss most of it
Automation is genuinely good at TLS configuration and will find an obsolete protocol reliably. It cannot determine that a field is sensitive, because sensitivity is a business judgement. Nothing in a national identity number distinguishes it from a reference code to a scanner, so data exposed through logging or an analytics pipeline is invisible to it.
How cryptographic failures gets fixed
- Classify data first — encryption decisions cannot be made correctly without knowing what you hold
- Use authenticated encryption and let a library choose parameters rather than assembling primitives by hand
- Store passwords with a memory-hard function and a per-user salt, and plan the rehash path in advance
- Move keys into a managed key service with rotation and audit, and separate them per environment
- Verify token signatures against a fixed expected algorithm rather than trusting the header
- Redact sensitive fields at the logging boundary so a new log line cannot leak them
Common questions
Is HTTPS enough to satisfy encryption requirements?
No. HTTPS protects data while it moves between client and server. It does nothing for data at rest, data in your logs, data in backups, data passed to third-party services, or data visible to anyone who can reach the storage layer. Most cryptographic findings we report sit entirely outside the transport path.
Does enabling storage encryption at rest protect us?
It protects against physical loss of the underlying media, which is rarely the threat that concerns an application team. If the encryption key is applied automatically to every authorised request, then any attacker who reaches the storage layer with valid credentials receives decrypted data. It is a necessary control and a genuine compliance requirement, but it is not application-layer protection.
How do you test encryption if you cannot see our keys?
We do not need key material. We test observable behaviour: what the application accepts, what it emits, whether ciphertext shows structural patterns, whether tokens survive tampering, and whether identical inputs produce identical outputs. Where you can share configuration and key management design we review it as well, which produces more precise remediation guidance.
Which password hashing algorithm should we use?
A memory-hard function designed for the purpose: Argon2id where your platform supports it, otherwise scrypt or bcrypt with a work factor tuned to your hardware. Never a general-purpose hash such as SHA-256, with or without a salt, because those are fast by design and speed is exactly what an offline attacker needs. Plan the rehash-on-login path before you migrate.
Do we need to encrypt data in our logs?
Usually you need to not put it there at all. Encrypting a log pipeline is harder than redacting at the point of writing, and logs are read by more systems and more people than your database. The durable fix is a logging layer that knows which fields are sensitive and strips them, so a developer adding a new log line cannot leak a record by accident.
Do you test our JWT implementation?
Yes, and it is one of the more productive areas. We check whether signatures are verified at all, whether the server trusts the algorithm named in the token header rather than a fixed expectation, whether the signing secret is weak enough to attack offline, and whether claims such as expiry, audience and issuer are actually enforced rather than merely present.
What TLS configuration do you expect to see?
TLS 1.2 as an absolute floor with 1.3 preferred, obsolete protocol versions disabled, forward-secret cipher suites only, HSTS enabled with a meaningful duration, and no mixed content. This part of the category is well served by automation and we report it briefly, because the findings that matter usually sit in how data is handled after the connection terminates.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.