Cryptography protects data only when algorithms, modes, keys and randomness are all right, and when you can replace them as standards change.
- Keep an inventory of keys, algorithms and certificates, with a plan to migrate them.
- Use approved algorithms and authenticated encryption through maintained libraries.
- Store passwords with an approved, computationally intensive key derivation function.
- Use a cryptographically secure random number generator for keys, tokens and nonces.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-11.1.1.
V11.1 Cryptographic Inventory and Documentation · 4 requirements
V11.1.1 Level 2
Verify that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such as NIST SP 800-57. This should include ensuring that keys are not overshared (for example, with more than two entities for shared secrets and more than one entity for private keys).
On this site: Envelope encryption and key rotation: data keys, KMS keys and backups (guide) · Case study: Storm-0558 and the forged Microsoft tokens (2023) (guide)
V11.1.2 Level 2
Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by the application. It must also document where keys can and cannot be used in the system, and the types of data that can and cannot be protected using the keys.
On this site: Envelope encryption and key rotation: data keys, KMS keys and backups (guide) · Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines (guide)
V11.1.3 Level 3
Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations.
On this site: Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines (guide)
V11.1.4 Level 3
Verify that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, such as post-quantum cryptography, in order to react to future threats.
On this site: Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines (guide)
V11.2 Secure Cryptography Implementation · 5 requirements
For the whole section: Choose cryptographic algorithms and parameters by job (guide)
V11.2.1 Level 2
Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations.
On this site: AEAD records: AES-GCM nonces, associated data and key limits (guide)
V11.2.2 Level 2
Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, rounds, ciphers and modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This will allow for seamless upgrades to post-quantum cryptography (PQC), once high-assurance implementations of approved PQC schemes or standards are widely available.
On this site: Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines (guide)
V11.2.3 Level 2
Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bit ECC key provides roughly 128 bits of security where RSA requires a 3072-bit key to achieve 128 bits of security.
On this site: Weak RSA key generation: shared primes, ROCA and safe keys (guide) · Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines (guide)
V11.2.4 Level 3
Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.
V11.2.5 Level 3
Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks.
On this site: Padding oracle attacks (guide) · Lucky Thirteen and POODLE: two different oracles (guide)
V11.3 Encryption Algorithms · 5 requirements
For the whole section: Choose cryptographic algorithms and parameters by job (guide)
V11.3.1 Level 1
Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used.
On this site: ECB mode: why it leaks patterns and what to use instead (guide) · DROWN: one RSA key across incompatible protocols (guide)
V11.3.2 Level 1
Verify that only approved ciphers and modes such as AES with GCM are used.
On this site: ECB mode: why it leaks patterns and what to use instead (guide) · RC4 keystream bias (guide) · 64-bit block ciphers and the Sweet32 mechanism (guide) · AEAD records: AES-GCM nonces, associated data and key limits (guide)
V11.3.3 Level 2
Verify that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an approved encryption method with an approved MAC algorithm.
On this site: ECB mode: why it leaks patterns and what to use instead (guide) · Padding oracle attacks (guide) · WEP: RC4 key reuse and weak IVs (guide) · AEAD records: AES-GCM nonces, associated data and key limits (guide) · Envelope encryption and key rotation: data keys, KMS keys and backups (guide)
V11.3.4 Level 3
Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of generation must be appropriate for the algorithm being used.
On this site: WEP: RC4 key reuse and weak IVs (guide) · AEAD records: AES-GCM nonces, associated data and key limits (guide) · Envelope encryption and key rotation: data keys, KMS keys and backups (guide)
V11.3.5 Level 3
Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode.
On this site: Padding oracle attacks (guide)
V11.4 Hashing and Hash-based Functions · 4 requirements
For the whole section: Choose cryptographic algorithms and parameters by job (guide)
V11.4.1 Level 1
Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose.
On this site: Hash collisions and digital signatures: MD5, SHA-1 and what to use (guide) · Flame: MD5 certificate forgery (guide)
V11.4.2 Level 2
Verify that passwords are stored using an approved, computationally intensive, key derivation function (also known as a "password hashing function"), with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks sufficiently challenging for the required level of security.
On this site: Password storage: hashing parameters and rehash on login (guide) · Case study: the LastPass breach (2022) (guide)
V11.4.3 Level 2
Verify that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths. If collision resistance is required, the output length must be at least 256 bits. If only resistance to second pre-image attacks is required, the output length must be at least 128 bits.
On this site: Hash collisions and digital signatures: MD5, SHA-1 and what to use (guide) · Flame: MD5 certificate forgery (guide)
V11.4.4 Level 2
Verify that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in use must balance security and performance to prevent brute-force attacks from compromising the resulting cryptographic key.
V11.5 Random Values · 2 requirements
For the whole section: Choose cryptographic algorithms and parameters by job (guide)
V11.5.1 Level 2
Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition.
On this site: Secrets management: storage, rotation and leaked-secret response (guide) · Weak RSA key generation: shared primes, ROCA and safe keys (guide) · Account recovery: password resets, help-desk resets and account linking (guide) · Insecure randomness for security tokens (fix card)
V11.5.2 Level 3
Verify that the random number generation mechanism in use is designed to work securely, even under heavy demand.
On this site: Insecure randomness for security tokens (fix card)
V11.6 Public Key Cryptography · 2 requirements
For the whole section: Choose cryptographic algorithms and parameters by job (guide)
V11.6.1 Level 2
Verify that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verification. Key generation algorithms must not generate insecure keys vulnerable to known attacks, for example, RSA keys which are vulnerable to Fermat factorization.
On this site: Weak RSA key generation: shared primes, ROCA and safe keys (guide) · ROCA: structured RSA key generation (guide)
V11.6.2 Level 3
Verify that approved cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This will prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks.
On this site: FREAK and Logjam: export-grade key exchange (guide)
V11.7 In-Use Data Cryptography · 2 requirements
V11.7.1 Level 3
Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes.
V11.7.2 Level 3
Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible.
On this site: Data minimization and retention: collect less and prove that deletion works (guide)
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
ECB mode: why it leaks patterns and what to use instead
Derive exactly what ECB reveals and why a longer key cannot fix it, find where ECB enters real code, and replace it with an authenticated mode.
Padding oracle attacks
Use a byte-level CBC example to see how a tiny validity signal becomes plaintext information, then design verification that checks more than the error message.
Hash collisions and digital signatures: MD5, SHA-1 and what to use
Distinguish collisions from preimages, follow a colliding pair through signing and verification, and retire MD5 and SHA-1 from the verifiers that still accept them.
Weak RSA key generation: shared primes, ROCA and safe keys
Recover a toy RSA factor with a greatest common divisor, distinguish shared primes, structured primes, duplicate keys and key length, and check a fleet of real public keys.
RC4 keystream bias
Understand why fresh RC4 keys do not remove keystream bias and how repeated secret positions turn a small statistical effect into evidence.
64-bit block ciphers and the Sweet32 mechanism
Calculate the birthday effect for 64-bit blocks and derive the CBC relation that can turn a collision into a plaintext disclosure.
Password storage: hashing parameters and rehash on login
Choose Argon2id, scrypt, PBKDF2 or bcrypt with current minimum parameters, store a versioned hash, and upgrade old hashes after a successful login without overwriting a reset.
AEAD records: AES-GCM nonces, associated data and key limits
Build an encrypted record whose tag binds ciphertext to the intended tenant, record, purpose and format, keep nonces unique within each key’s usage limit, and verify the design with actual AES-GCM.
Envelope encryption and key rotation: data keys, KMS keys and backups
Encrypt each record with its own data key, wrap that key in a KMS or HSM key, and keep wrapping-key rotation, data re-encryption, key deletion and restored backups as separate, tested operations.
Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines
Inventory public-key cryptography by operation, owner and lifetime, turn on hybrid ML-KEM key exchange where it is already available, and plan signature and archive migration against the NIST, NSA, NCSC and EU dates.
WEP: RC4 key reuse and weak IVs
Separate WEP’s repeated-keystream failure, weak-IV key recovery, and unkeyed integrity weakness through a concrete two-packet exercise.
Flame: MD5 certificate forgery
Follow how a weak digest and an overpowered certificate trust path enabled forged code-signing authority, without equating the event with RSA key theft.
Lucky Thirteen and POODLE: two different oracles
Compare two CBC oracles by their signal, protocol rules, and attacker prerequisites instead of treating them as interchangeable padding bugs.
FREAK and Logjam: export-grade key exchange
Trace two export-grade downgrade paths and separate RSA factorization from finite-field Diffie–Hellman discrete logarithms.
DROWN: one RSA key across incompatible protocols
Map an RSA key across services to see how an SSLv2 oracle could compromise TLS traffic on a different endpoint.
Sweet32: the cost of a small block size
Read the 2016 Sweet32 demonstrations as evidence about traffic volume, repeated secrets, and session lifetime rather than treating a block-size threshold as an instant exploit.
ROCA: structured RSA key generation
Understand why mathematically structured RSA primes were factorable despite normal key lengths, then plan replacement around generation provenance.
Practice
References
- V11 Cryptography (ASVS 5.0.0 source)
- OWASP Web Security Testing Guide: Testing for Weak Cryptography
- OWASP Cryptographic Storage Cheat Sheet
- FIPS 140-3
- NIST SP 800-57
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.