Cryptographic Failures: Following the Data and the Keys

Cryptographic Failures is the fourth category in my OWASP Top 10:2025 study notes.

The material covers missing protection, weak or inappropriate cryptography, poor key handling, and mistakes in how otherwise sound cryptographic tools are used.

To organize the topic, I started with two questions: what data needs protection, and where does that data go?

Start with the data

An application may handle passwords, customer information, business records, or other data that needs protection. That data can move through browser requests, application services, databases, logs, caches, and backups.

Understanding those paths helps identify where controls are needed. It also raises a more basic question: does the application need to collect or retain this information in the first place?

Keeping unnecessary sensitive data creates additional exposure and additional work to protect it. Retention decisions are part of the security design.

Encryption in transit and at rest

For web traffic, properly configured HTTPS uses TLS to protect information in transit. That protection depends on details such as certificate validation, supported protocol versions, and consistently enforcing secure connections.

Data stored in a database or backup presents a different set of questions. What is encrypted? Who can read it? Where are the keys? What happens when the data is exported or copied?

Encryption at rest can help protect stored data, but the protection depends on the threat being addressed. An attacker using an authorized application's access may still be able to retrieve data that the application can decrypt.

This connects cryptography back to access control and secure configuration.

Password storage deserves its own treatment

For ordinary password authentication, the application needs to verify a submitted password without storing a recoverable copy of it.

That is why the guidance points to password hashing designed for the purpose, with a unique salt and an appropriate work factor. A general-purpose fast hash is not an adequate substitute just because it produces an unreadable-looking value.

The OWASP Password Storage Cheat Sheet provides current recommendations, including Argon2id and guidance for other supported choices and constraints. The implementation settings matter as much as recognizing an algorithm's name.

The keys need protection too

A strong encryption algorithm offers limited protection if its key is exposed alongside the data.

Key management includes generation, storage, access, use, rotation or replacement, and eventual retirement. Keys should not be hard-coded into source code or treated as ordinary application settings.

Managed key services or hardware-backed options may help, depending on the system's requirements. They still need appropriate permissions and operational procedures.

Use the tools according to their requirements

Cryptographic libraries provide building blocks with specific requirements. Secure randomness, nonce or initialization-vector handling, and verification of authentication tags can all affect whether an implementation is safe.

Different algorithms and modes have different rules. For example, reusing a nonce with the same key can seriously undermine modes that require nonce uniqueness. Treating every mode as interchangeable can introduce a vulnerability even when the underlying algorithm is strong.

For application work, the safer starting point is a maintained, well-reviewed library and its supported high-level interfaces, following current guidance rather than inventing a custom scheme.

Questions for my notes

What sensitive data is collected, and how long is it retained?
Is it protected along each relevant transmission and storage path?
Are passwords handled with an appropriate password-hashing function?
Where are the keys, and which identities can use them?
Are certificate checks and other cryptographic verification steps enforced?
Does the implementation follow the chosen library's requirements?

What connects the first four categories

These first four deep dives overlap in useful ways. Access control decides who can use data and features. Configuration shapes the deployed environment. Supply-chain controls help protect what becomes a release. Cryptography protects data under specific conditions and assumptions.

My next step in studying a particular implementation would be to use the detailed guidance for that feature and technology. The Top 10 provides a useful map of the risks; the implementation details still need their own attention.

Sources and further reading