Data Security Insights

Practical Guidance for Preventing OWASP Cryptographic Failures

A practical checklist for preventing OWASP Cryptographic Failures across data classification, retention, encryption, key management, randomness, password storage, and verification.

Reviewed August 1, 2026

Cryptographic failures are not limited to missing encryption. They include weak algorithms, exposed keys, nonce reuse, insecure password storage, unnecessary retention, poor transport security, and configurations that have never been independently verified.

OWASP’s Cryptographic Failures category focuses attention on the root causes that lead to sensitive-data exposure. The practical goal is not to “add encryption” everywhere. It is to identify sensitive data, choose the right protection, manage keys throughout their lifecycle, and verify that the complete implementation works as intended.

1. Classify sensitive data

Inventory data processed, stored, and transmitted by each application. Classify it according to legal obligations, contractual requirements, business sensitivity, and the harm created by exposure. Connect classifications to concrete retention, access, encryption, tokenization, and masking requirements.

2. Minimize retention

Data that is not retained cannot be stolen from storage. Remove unused fields, shorten retention periods, and prefer truncation or appropriate tokenization when the original value is not required. Do not substitute FPE for tokenization automatically. They have different architectures and risk profiles.

3. Protect data at rest and in transit

Use strong, standard protection appropriate to the threat model. Storage-level encryption helps with lost media and some infrastructure threats, but may not protect data after an authorized system or compromised identity obtains access. Transport encryption protects network connections but ends at the TLS termination point.

For sensitive fields, consider protection closer to the data and application workflow so cleartext is limited to the identities and operations that require it.

4. Use current, standard cryptography

Use maintained libraries and approved algorithms rather than custom cryptography. For general-purpose symmetric encryption, prefer authenticated encryption such as AES-GCM or AES-CCM when supported. Avoid ECB for secret data. Treat algorithm selection, key length, mode, nonce rules, and validation requirements as one configuration decision.

5. Manage keys through their lifecycle

NIST describes key management as the secure generation, storage, distribution, use, and destruction of cryptographic keys. Add inventory, ownership, rotation, revocation, backup, recovery, compromise response, and auditability to that lifecycle.

  • Do not hardcode keys or commit them to source control.
  • Separate keys by environment, tenant, purpose, and protection boundary where required.
  • Restrict key access through least privilege.
  • Keep a reliable mapping between ciphertext and the key or version needed to process it.
  • Test rotation and recovery before an incident.

6. Store passwords with password hashing

Passwords should not be stored with reversible encryption. Use a purpose-built, adaptive, salted password-hashing function with an appropriate work factor, such as Argon2id, scrypt, bcrypt, or PBKDF2 where required by the applicable standard and platform.

7. Handle nonces, IVs, and randomness correctly

Generate keys and security-sensitive random values with a cryptographically secure random-number generator. Follow the exact IV or nonce requirements for the selected mode. For AES-GCM, nonce reuse under the same key can undermine confidentiality and authentication.

Distributed systems must prevent reuse across processes, replicas, restarts, restored backups, and regional failover. “The library generates a nonce” is not enough if the system-level design can repeat it.

8. Use authenticated encryption

Encryption alone may not detect malicious modification. AEAD modes protect confidentiality and produce an authentication tag for ciphertext and associated data. Verify the tag before releasing plaintext, fail closed on any mismatch, and avoid exposing detailed cryptographic errors to untrusted callers.

9. Disable unsafe caching and legacy transport

Prevent sensitive responses from being stored in browser or intermediary caches when the workflow does not require it. Do not transmit sensitive data over plaintext legacy protocols. Use current TLS configurations, HSTS for HTTPS, and secure service-to-service transport.

10. Verify the implementation independently

Configuration should be reviewed by security specialists and tested with appropriate tools. Validate the full data path, not only the algorithm name.

  • Confirm sensitive fields are protected in storage, logs, queues, backups, and analytics systems.
  • Test unauthorized and malformed requests.
  • Verify key rotation and revocation behavior.
  • Check for plaintext in caches, errors, telemetry, and temporary files.
  • Review cryptographic dependencies and standards on a defined schedule.

Cryptography does not replace access control

Strong encryption can still expose data when a compromised or overprivileged identity is allowed to decrypt it. The customer’s identity system establishes the requester. Data-specific policy must determine whether that identity receives authorized cleartext or a protected representation.

The bottom line

Preventing cryptographic failures requires coordinated data classification, minimization, current algorithms, authenticated encryption, key lifecycle management, secure randomness, password hashing, transport security, access control, and independent verification. No single encryption API or product setting can replace that system.

Explore Ubiq’s approach to Runtime Data Protection, or review the related OWASP Cryptographic Failures overview.

Sources