Common Cryptography Mistakes

# CHAPTER 16

Common Cryptography Mistakes #

1. Introduction #

Cryptographic failures rarely make the news because a mathematician solved a 300-year-old equation. They make the news because a developer made a copy-paste error, an administrator forgot to renew a certificate, or an organization chose speed over security. The math is robust; the human implementation is deeply flawed. In this chapter, we will perform a post-mortem on the most pervasive cryptographic mistakes found in the industry, learning how to identify and eradicate these vulnerabilities before they lead to catastrophic breaches.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Identify the danger of Hardcoded Secrets in source code.

• Understand the vulnerability of using weak or predictable randomness (PRNGs).

• Recognize the security failure of using deprecated algorithms (MD5, DES).

• Understand the concept of Downgrade Attacks in TLS configurations.

• Identify the flaws in poorly implemented password systems.

3. Beginner-Friendly Explanation #

Imagine a high-tech bank vault.

• Hardcoding Secrets: The bank manager buys the best vault in the world, but writes the combination on a sticky note and leaves it stuck to the vault door.

• Weak Randomness: The vault uses a combination lock. The manager decides the combination will always be the current year followed by the current month (e.g., 202410). It takes a thief 3 seconds to guess it.

• Deprecated Algorithms: The bank refuses to upgrade its 50-year-old rusty padlock because buying a new one is "too expensive," even though lockpicks for that padlock are sold at every hardware store.

These are not failures of the vault technology; they are failures of human operational security.

4. Mistake 1: Hardcoded Secrets #

This is the most common and devastating mistake in modern development. A developer writes a script to automatically pull data from a database. To make the script work, they type the database password (or the API key, or the AWS KMS key) directly into the Python code. They then upload the code to a shared repository like GitHub. The Vulnerability: Anyone who can read the code has the master keys to the kingdom. Automated bots scan public GitHub repositories 24/7. If you accidentally push an AWS API key to public GitHub, bots will find it and use it to compromise your cloud account within 5 minutes. The Fix: Use Environment Variables or a secure Secrets Vault (like HashiCorp Vault or AWS Secrets Manager).

5. Mistake 2: Weak Random Numbers #

Cryptography relies entirely on unpredictability. When generating a Session Cookie, an Encryption Key, or a Salt, the computer must generate a random number. Standard programming functions like Math.random() or rand() are Pseudo-Random. They use predictable mathematical formulas based on the system clock. If a hacker knows exactly what time the server started, they can mathematically predict every "random" session token the server generates. The Fix: Always use a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), such as /dev/urandom in Linux or random_bytes() in PHP, which uses environmental noise (hardware temperature, mouse movements) to ensure true, unpredictable randomness.

6. Mistake 3: Using Deprecated Algorithms #

Legacy systems are dangerous. Many older applications still use MD5 or SHA-1 for hashing passwords or verifying data integrity. Others might still use DES or 3DES for encryption. These algorithms have been mathematically broken for years. Modern GPUs can crack MD5 hashes in fractions of a second. The Fix: Security teams must actively audit legacy codebases. Upgrade all hashing to SHA-256 (for files) or Bcrypt/Argon2 (for passwords). Upgrade all symmetric encryption to AES-256.

7. Mistake 4: TLS Downgrade Attacks and Weak Ciphers #

When configuring a web server (like Nginx or Apache), administrators often try to support very old web browsers by enabling outdated protocols like SSL v3.0 or TLS 1.0. The Vulnerability: If a server supports both TLS 1.3 (Secure) and TLS 1.0 (Broken), an attacker performing a Man-in-the-Middle attack can intercept the initial connection and force the server and the browser to agree to use the broken TLS 1.0 protocol (a Downgrade Attack). The attacker then breaks the weak encryption and steals the data. The Fix: Administrators must ruthlessly disable support for anything older than TLS 1.2 on their web servers.

8. Mini Project: Audit Insecure Cryptographic Examples #

Let's look at bad code and identify the flaws.

Bad Code Example (PHP):

How an Attacker Exploits This:

• They read the source code and steal the $apiKey.

• They guess the output of rand() and forge a $sessionToken to hijack an account.

• They steal the database, and use a Rainbow Table to reverse the unsalted md5 password hash instantly.

9. Real-World Scenarios #

In 2011, Sony suffered a massive breach of the PlayStation Network, resulting in the theft of 77 million accounts, including credit card data. The breach was a masterclass in cryptographic failures. While the exact details remain debated, investigations revealed a catastrophic combination of errors: unpatched Apache servers, storing user passwords in plaintext or using un-salted hashes, and storing credit card data on systems connected directly to the internet without proper internal encryption segmentation. The failure was a total breakdown of fundamental cryptographic best practices.

10. Legal and Ethical Notes #

When conducting a security assessment, identifying hardcoded credentials in source code is often categorized as a "Critical" finding. The ethical obligation of a security professional is to immediately halt the assessment, notify the client, and assist in rotating (invalidating) the compromised keys before resuming the test.

11. Exercises #

1. 1. Explain why using Math.random() to generate a cryptographic key is a severe vulnerability. What must be used instead?

1. 2. Describe a TLS Downgrade attack. How can a server administrator prevent it?

12. FAQs #

Q: Is it safe to hide my encryption keys by obfuscating the code? A: No. Code obfuscation (making code hard to read) is Security through Obscurity. A determined reverse-engineer will de-obfuscate the code, find the key, and break the system. Keys must never be stored in the client-side code (like JavaScript or mobile apps).

13. Interview Questions #

• Q: You are reviewing a pull request and notice a developer has committed an AWS API key to a public repository. Detail the immediate incident response steps you would take to mitigate this risk.

• Q: Explain the difference between a standard Pseudo-Random Number Generator (PRNG) and a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). In what scenarios is a CSPRNG mandatory?

14. Summary #

In Chapter 16, we analyzed the human failures that undermine perfect mathematics. We identified Hardcoded Secrets as the most pervasive vulnerability in modern development. We explored how predictable randomness allows attackers to forge tokens, and how clinging to deprecated algorithms like MD5 and SSL v3.0 leaves systems wide open to legacy attacks. By learning to recognize these common anti-patterns, we empower ourselves to architect systems that are secure in reality, not just in theory.

15. Next Chapter Recommendation #

We have examined internal application flaws. But modern applications constantly talk to external systems and third-party services. How do we secure those conversations? Proceed to Chapter 17: Secure APIs and Authentication Systems.