scanrub
Missing Required Cryptographic Steplow prioritynot yet scanned

Missing Required Cryptographic Step

2 min read 3 reports analyzed ScanRub Research
Share

Summary

A cryptographic protocol or scheme is implemented with one of its required steps skipped or incorrectly ordered - verifying a MAC before decrypting instead of after (or not at all), skipping a required padding check, or omitting a step a protocol specification mandates for security. The individual cryptographic primitives used may all be sound; the flaw is in the assembly, where the specific sequence of operations matters as much as which operations are used.

◈ flow diagram
Cryptographi…Weak Mode, I…Ciphertext L…Data Recover…

Why This Requires More Than a Black-Box Scan

Confirming a missing protocol step requires reading the actual implementation against the protocol's specification - a source-level correctness check, not something inferable from observing the resulting ciphertext or protocol messages alone.

Where This Is Actually Caught

Source-level cryptographic protocol review, checking the actual sequence of operations against the specification the protocol claims to implement.

Tip: Source-level cryptographic review — checking library usage, mode selection, IV/nonce generation, and key management against known-good patterns — is the standard way these are caught, ideally by someone with applied-cryptography experience rather than general code review, since a broken implementation and a correct one produce identical-looking ciphertext from outside.

Real-World Impact

Real-World Impact

This family covers cryptographic implementation mistakes that don't fit one of the more specific named categories: using a correct algorithm with a subtly wrong mode (ECB instead of CBC/GCM), a static or predictable IV/nonce, insufficient key length, a missing verification step in a protocol, or a home-grown scheme instead of a vetted primitive. The common thread across all of them is that the mistake usually looks identical to a correct implementation from outside — the same ciphertext-shaped bytes come back either way — so the flaw only becomes visible when you know how the encryption is actually implemented, not just that encryption is happening at all.

The practical consequences range from an attacker being able to distinguish or manipulate ciphertext (a broken mode or reused nonce can leak plaintext relationships or allow forgery) to full recovery of encrypted data (a weak algorithm, insufficient key length, or a completely broken home-grown scheme). Missing or incomplete verification steps, like an incomplete signature check, can additionally let an attacker forge data the application trusts as authentic.

Because these bugs are invisible from outside the implementation, they persist far longer on average than input-validation bugs — a broken cryptographic scheme frequently ships and stays in production for years before a code-level review or an academic cryptanalysis surfaces it.

Prevention & Remediation

Prevention and Secure Design

Preventing Missing Required Cryptographic Step takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Use vetted, high-level cryptographic libraries — never build a custom scheme. A well-reviewed library's default, recommended API (not its low-level primitives used incorrectly) is dramatically safer than any custom construction, however simple the requirement seems.

Use authenticated encryption modes. Prefer AEAD modes (AES-GCM, ChaCha20-Poly1305) over unauthenticated modes like ECB or plain CBC, which don't protect integrity and are vulnerable to a range of well-known attacks.

Generate IVs and nonces correctly, every time. A nonce must never repeat under the same key — use the library's recommended generation method rather than a fixed or predictable value.

Keep key lengths and algorithm choices current. Cryptographic recommendations shift as computational power and cryptanalysis advance — periodically re-validate algorithm and key-length choices against current guidance rather than what was correct when the code was written.

Have cryptographic code reviewed by someone with applied-cryptography experience. General code review reliably misses subtle mode, IV, or verification-step mistakes that a cryptography-focused reviewer catches immediately.

Frequently Asked Questions

What is Missing Required Cryptographic Step?
A cryptographic protocol or scheme is implemented with one of its required steps skipped or incorrectly ordered - verifying a MAC before decrypting instead of after (or not at all), skipping a required padding check, or omitting a step a protocol specification mandates for security.
How common is Missing Required Cryptographic Step in bug bounty reports?
Scanrub's research corpus for this playbook is built from 3 disclosed HackerOne reports in this category, synthesized for detection and prevention guidance rather than reproduced verbatim.
Can Missing Required Cryptographic Step be found with an automated scanner?
Not reliably on its own — this class typically requires the kind of review described in "Where This Is Actually Caught" above (code-level review, fuzzing, red-teaming, or design review, depending on the specific mechanism), rather than an HTTP-level black-box scan.
What is the single most effective fix for Missing Required Cryptographic Step?
Use a vetted, high-level cryptographic library with authenticated encryption modes — never build a custom cryptographic scheme, and never reuse an IV or nonce under the same key.
Weekly security research

New vulnerability playbooks, tool updates, and bug bounty insights - delivered to your inbox. No spam.

Unsubscribe anytime. We respect your inbox.
Press ⌘K to search×