Unlearning Curve: Five Crypto Habits Working Engineers Should Retire This Year
Photo: Luc Saffre, CC BY-SA 4.0, via Wikimedia Commons
Most cryptographic failures in production software are not exotic. They are the residue of habits learned early, repeated under deadline, and never revisited. The habits below are common precisely because they are easy, and they are dangerous precisely because they usually work — right up until the day they don't.
1. Rolling Your Own Nonce Generation
The failure mode: In AES-GCM and ChaCha20-Poly1305, reusing a nonce with the same key is not a subtle weakness — it is catastrophic, recovering the plaintext stream and the authentication key. Yet developers routinely generate nonces with counters stored in unreliable places, or with random() from a non-cryptographic source.
The alternative: Use a cryptographically secure random source (crypto/rand in Go, getrandom() on Linux, BCryptGenRandom on Windows) for every nonce, or better, use XChaCha20-Poly1305 or AES-GCM with a large random nonce where the library supports it, making collisions statistically negligible. If you must use a counter, let a vetted library manage it.
2. Treating SHA-256 as Encryption
The failure mode: Passwords "hashed" with a bare SHA-256 and stored. Hashing is one-way by design; it is not encryption, and a fast hash is an invitation to offline cracking at billions of guesses per second on commodity GPUs.
The alternative: For passwords, use Argon2id, scrypt, or bcrypt — memory-hard functions built for exactly this job. For data that needs to be recoverable, use authenticated encryption (AES-GCM, XChaCha20-Poly1305). If you can name the difference between hashing and encryption without hesitation, you are ahead of a lot of production code.
3. Hardcoding Salt and Calling It a Pepper
The failure mode: A fixed salt string baked into the source. Salt exists to make each hash unique; a hardcoded salt means every user with the same password produces the same hash, and rainbow tables can be precomputed against your specific deployment.
The alternative: Generate a fresh random salt per credential and store it alongside the hash — salts are not secrets. If you want a secret value in the mix, that is a pepper, and it belongs in a KMS or secrets manager, not in a repository. Better yet, let Argon2id handle salting automatically and delete the custom code.
4. Copying Crypto Snippets From Stack Overflow
The failure mode: The most upvoted answer to "how do I encrypt in Python" has historically suggested ECB mode or a homegrown XOR scheme. Snippet-driven development propagates code that compiles, runs, and is quietly wrong — often missing authentication, using static IVs, or misusing padding.
The alternative: Start from the library documentation, not the Q&A. libsodium, Tink, and the standard cryptographic libraries in Go and Rust are designed so that the easy path is the safe path. If a snippet you found requires you to think about block modes, you are using the wrong abstraction level.
5. Building Your Own Key Derivation
The failure mode: MD5(password + "app-salt") used to derive encryption keys, or SHA-256 applied once to a passphrase. Low-entropy secrets need deliberate, expensive stretching; ad hoc derivation produces keys that fall to a GPU rig in hours.
The alternative: HKDF for deriving keys from high-entropy material, and Argon2id or scrypt when the input is a human password. Both are one-call APIs in every mainstream language.
The Common Thread
Each of these habits shares a root cause: treating cryptography as a string-manipulation problem rather than a systems problem. The fix is not memorizing more theory — it is deferring to audited libraries, choosing the boring modern default, and asking one question before shipping: what does this look like on an attacker's machine? Retiring five habits is a modest price for that answer.
