Cryptographic Practices

5.4.3 Cryptographic practices

Here is a collection of Do’s and Don’ts when it comes to cryptographic practices, gathered from practical experiences.

• The basis for usage of PKI is to address (using encryption and hashing)
• Confidentiality
• Integrity
• Authentication
• Non-repudiation
• Cryptography is used for the following:
  • Data-at-rest protection using data encrypting keys and key encrypting keys. For which,
• Do not use custom cryptographic algorithms / deprecated algorithms
• Do not use passwords as cryptographic keys
• Do not hard-code cryptographic keys in the application
• Persist secret keys in a secure vault like HSM, KMS, Secrets Manager
• Manage encryption keys through the lifecycle, including key retirement/replacement when someone who has access leaves the organisation
• Rotate keys on a regular basis. However this depends on the key strength and the algorithm used. If the key strength is low, the rotation period will be smaller
• Maintain a contingency plan to recover data in the event of an encrypted key being lost
• Ensure the code eliminates secrets from memory.
• Maintain a contingency plan that can recover data in the event of an encrypted key being lost
• Store keys away from the data
• Do not use IV twice for a fixed key
• Communication security
• Ensure no sensitive data is transmitted in the clear, internally or externally.
• Validate certificates properly against the hostnames/users for whom they are meant
• Failed TLS connections should not fall back to an insecure connection
• Do not use IV twice for a fixed key
• Cryptography in general
• All protocols and algorithms for authentication and secure communication should be well vetted by the cryptographic community.
• Perform Message integrity checking by using a combined mode of operation, or a MAC based on a block cipher.
• Do not use key sizes less than 128 bits or cryptographic hash functions with output sizes less than 160 bits.
• Do not use custom cryptographic algorithms that have not been vetted by cryptography community
• Do not hardcode cryptographic keys in applications?
• Issue keys using a secure means.
• Maintain a key lifecycle for the organisation (Creation, Storage, Distribution and installation, Use, Rotation, Backup, Recovery, Revocation, Suspension, Destruction)
• Lock and unlock symmetric secret keys securely
• Maintain CRL (Certificate Revocation Lists) maintained on a real-time basis
• Validate certificates properly against the hostnames/users for whom they are meant
• Ensure the code eliminates secrets from memory
• Specific encryption, in addition to SSL
• Mask or remove keys from logs
• Use salted hashes when using MD5 or any such less secure algorithms
• Use known encryption algorithms, do not create your own as they will almost certainly be less secure
• Persist secret keys in a secure vault like HSM, KMS, Secrets Manager
• Do not use IV twice for a fixed key
• Ensure that cryptographic randomness is used where appropriate, and that it has not been seeded in a predictable way or with low entropy. Most modern APIs do not require the developer to seed the CSPRNG to get security.

The OWASP Developer Guide is a community effort; if there is something that needs changing then submit an issue or edit on GitHub.

\newpage