Skip to main content

Cryptographic Failures

Premium

Cryptographic failures are among the most common and costly security issues in the real world. As a security engineer, you’re expected to spot design mistakes, explain their impact, and propose practical fixes. Strong candidates focus on impact and prevention, not theory.

Interviewers want to see that you can:

  • Identify cryptographic design or implementation mistakes.
  • Explain how those mistakes lead to breaches, integrity loss, or privilege escalation.
  • Propose realistic mitigations that match industry best practices.

What to expect

Typical interview prompts include:

  • “What are some common mistakes teams make when implementing encryption?”
  • “What is the most common mistake you’ve seen with key management?”

Expect both quiz-style and scenario-based questions on cryptographic failures.

Common cryptographic failures

The table below shows the most common cryptographic mistakes you’ll encounter in real systems. This is the level of understanding interviewers expect: What went wrong? Why is it dangerous? And how do engineers fix it?

FailureDescriptionImpactPrevention
Using outdated algorithmsContinued use of MD5, SHA1, DES, or RC4.Predictable hashes or weak encryption.Use modern algorithms (AES-256, SHA-256, RSA-2048).
Hardcoded or shared keysKeys stored directly in code or configs.Key disclosure and large-scale compromise.Store keys in managed services (KMS, Vault, HSM).
Lack of key rotationKeys never replaced or revoked.Increased exposure if keys leak.Rotate regularly and automate through KMS or policy.
Missing randomnessPredictable IVs, salts, or nonces.Repeated ciphertext patterns or collisions.Use cryptographically secure random generators.
Incorrect use of hashingStoring unsalted or fast hashes for passwords.Enables brute-force attacks.Use bcrypt, scrypt, or Argon2 with unique salts.
Improper certificate validationAccepting self-signed or invalid certificates.Enables man-in-the-middle attacks.Verify signatures and enforce certificate pinning.
Encrypting without integrity checksEncryption without MAC or signature.Allows ciphertext manipulation.Use authenticated encryption (AES-GCM, ChaCha20-Poly1305).
Custom crypto implementationsDevelopers create their own encryption logic.Unverified, insecure behavior.Use vetted, peer-reviewed libraries only.

Cryptographic failures usually stem from misuse, not broken math.

Real-world cases

You can read up on and reference these examples to show awareness of industry incidents:

  • Heartbleed (2014): OpenSSL buffer over-read leaked private keys, passwords, and session data from memory.
    • Lesson: crypto library bugs can expose secrets; audit critical dependencies.
  • WannaCry (2017): EternalBlue exploit leveraged weak SMBv1 crypto to spread ransomware globally.
    • Lesson: deprecate weak protocols, patch cryptographic flaws urgently.
  • Zoom (2020): Used ECB mode encryption + 128-bit keys despite claiming 256-bit end-to-end encryption.
    • Lesson: secure defaults and honest security claims matter.
  • GitHub (2023): RSA SSH keys generated via weak RNG needed mass revocation.
    • Lesson: key generation flaws require immediate rotation and revocation.

Referencing these briefly positions you as someone who follows industry patterns

Next Lesson