Accueil / retour à la liste

Cryptographic Failures

2) Cryptographic Failures

What this means (simple)

A cryptographic failure happens when sensitive data is not protected correctly.

Sensitive data includes:

  1. Passwords
  2. Credit card numbers
  3. Personal data (name, phone, address, ID)
  4. API keys and tokens
  5. Session cookies

If protection is weak, attackers can read, steal, or change data.

Very common real-life situations

  1. Passwords are stored as plain text in the database.
  2. Passwords are hashed with weak algorithms like MD5 or SHA1.
  3. Website uses HTTP instead of HTTPS, so data travels in clear text.
  4. Encryption keys are hardcoded in source code.
  5. Old TLS settings are enabled (weak ciphers/protocols).
  6. Sensitive data is logged in application logs.

Step-by-step: how an attack happens

Scenario A: Plain-text passwords

  1. Attacker finds SQL injection or steals DB backup.
  2. Attacker opens users table.
  3. Password column contains real passwords (password123, qwerty).
  4. Attacker logs into user accounts immediately.
  5. Attacker tries same passwords on other websites (credential stuffing).

Scenario B: Weak password hashing

  1. App stores hashes using MD5.
  2. Attacker steals hash list.
  3. Attacker runs fast cracking tools with rainbow tables/GPU.
  4. Many passwords are recovered in minutes/hours.
  5. Accounts are taken over.

Scenario C: No HTTPS

  1. User logs in on public Wi-Fi.
  2. Traffic is sent over HTTP.
  3. Attacker sniffs network packets.
  4. Attacker reads username/password or session cookie.
  5. Attacker hijacks session and acts as user.

Tricky concepts explained clearly

1) Encryption vs Hashing

  1. Encryption is reversible.
  2. Hashing is one-way.

Think:

  1. Encryption = locked box with a key. If you have key, you can open it.
  2. Hashing = blender. You cannot “unblend” it.

Use:

  1. Passwords: hashing (never decrypt passwords).
  2. Data like card numbers: encryption (you may need to read later).

2) Salt

A salt is random data added to each password before hashing.

Why:

  1. Two users with same password should not have same hash.
  2. It blocks many precomputed attacks (rainbow tables).

Rule:

  1. Use unique random salt per password.
  2. Store salt with hash (this is normal and safe).

3) Pepper

A pepper is a secret extra value (like app-wide secret) added before hashing.

Why:

  1. If DB is stolen, attacker still misses pepper.
  2. Adds extra defense.

Rule:

  1. Keep pepper outside DB, e.g., secret manager.

4) Key management

Encryption is only as strong as key handling.

Bad:

  1. Key in source code
  2. Key in Git repo
  3. Same key forever

Good:

  1. Store keys in KMS/secret manager
  2. Rotate keys
  3. Limit who can access keys
  4. Log key usage

5) “Data in transit” vs “data at rest”

  1. In transit = moving over network
  2. At rest = stored in DB/files/backups

Need both:

  1. HTTPS/TLS for in transit
  2. Proper encryption/hashing for at rest

6) Randomness

Crypto needs strong random numbers.

Bad:

  1. Using predictable random (Math.random) for tokens/IVs

Good:

  1. Use cryptographically secure random generator from your platform.

How to prevent (implementation steps)

  1. List all sensitive data your app handles.
  2. Remove data you do not need to store.
  3. Enforce HTTPS everywhere.
  4. Set Secure, HttpOnly, SameSite on cookies.
  5. Hash passwords with Argon2id (or bcrypt/scrypt if needed).
  6. Use per-user random salt for password hashes.
  7. Encrypt sensitive stored data using modern authenticated encryption (like AES-GCM).
  8. Keep keys in a secrets manager/KMS, not code.
  9. Disable old protocols/ciphers (SSL, TLS 1.0/1.1).
  10. Never log passwords, tokens, or full card data.
  11. Add automated checks for weak crypto use.
  12. Rotate keys and secrets regularly.

Password storage: correct flow (easy model)

  1. User sends password at signup.
  2. Server generates random salt.
  3. Server computes Argon2id(password + salt + optional pepper).
  4. Server stores: hash + salt + algorithm parameters.
  5. On login, server recomputes hash and compares.
  6. Server never decrypts or shows password because it is not stored in reversible form.

Quick “bad vs good”

  1. Bad: MD5(password)

Good: Argon2id with strong parameters.

  1. Bad: HTTP login page

Good: HTTPS-only with HSTS.

  1. Bad: API key in source code

Good: API key in secret manager.

  1. Bad: Encrypt data but store key in same DB table

Good: Separate key storage with strict access control.