Secure Coding Practices for Cryptography
Domain 6: Secure Coding Practices for Cryptography
This domain tests correct use of cryptography for confidentiality, integrity, authenticity, and password storage. The exam rewards standard primitives and key management over custom schemes.
Core rules and concepts
- Use vetted libraries and standard constructions. Do not design your own cipher, mode, or protocol.
- For symmetric encryption, prefer authenticated encryption such as AES-GCM or ChaCha20-Poly1305. Never use ECB mode for structured data.
- Use cryptographically secure random number generators for keys, salts, IVs, nonces, and tokens. Never reuse a nonce with the same key in an AEAD scheme.
- Hash passwords with Argon2id, bcrypt, scrypt, or PBKDF2 using a per-user salt and an appropriate work factor. Hashing is not encryption.
- Protect data in transit with current TLS and data at rest with managed keys. Separate keys by purpose and environment.
- Manage keys: generate securely, store in a secrets manager or HSM, restrict access, rotate, and retire safely.
Worked example
A registration form stores passwords using SHA-256 without a salt. A sound design uses Argon2id with a unique random salt per password, a calibrated work factor, and constant-time verification through the library. The reasoning is that SHA-256 is fast, so offline guessing is cheap; a per-user salt prevents precomputed tables and identical-password correlation; a memory-hard function raises attacker cost; and constant-time comparison avoids timing leakage. The password is never encrypted because encryption is reversible and the application does not need the plaintext.
Traps that cost marks
Do not use MD5 or SHA-1 for security decisions. Do not use a static IV or nonce. Do not hardcode keys in source or configuration files. Do not confuse encoding, hashing, and encryption. Do not assume HTTPS protects data after it is stored. Do not use passwords as encryption keys without a proper derivation function.
Review habit
Identify what must be secret, what must be tamper-evident, and what must be verifiable; then choose the primitive and key lifecycle that match.