Security considerations when handling sensitive data

1. All data along with their criticality have been identified.
2. A matrix indicating the data and the means to secure it is available in the design document.
3. All data required to be kept confidential is encrypted.
4. All data that absolutely must not be tampered is digital signed using private key or using HMAC.
5. Private information (secrets) is not persisted to disk until necessary.
6. Private information (secrets) is kept in memory for only as longs as it is necessary.
7. Private information (secrets) are not stored as literal values in code (no hard-coded values)
8. Database connection information such as user name and password are not stored in plaintext on disk.
9. No sensitive data is stored in persisted cookies.
10. No custom-built algorithms are being used to encrypt data.
11. If standard algorithms are being used, then the library used to implement them are tested sufficiently. (Watch out for algos like AES, RSA etc. implemented by local app teams)
12. If standard algos are being used, there is a documented rationale for chosen key sizes.
13. The encryption key is stored in a secure manner.
14. There is a provision in the application for changing the keys used for encryption.
15. There is a provision in the application for rolling over data (i.e. data encrypted with "old" key to be re-encrypted using "new" key)
16. There is a provision in the application for handling scenarios like "lost key", "lost password to key" and "key compromise"
17. Sensitive data is not transmitted using GET, as it can be directly seen in the browser address bar.
18. Sensitive information is not being sent in the HTTP headers as these can be easily changed.
19. Audit logs are encrypted (if required) , but should be definitely be protected against tampering and loss of integrity.
20. Where possible, WS-Security or SSL/TLS is used to protect ephemeral data rather than implement crypto schemes out of primitives.
21. For .NET code, System.Security.Cryptography namespace will be used.
22. For Java code, JCE providers will be used (Bouncycastle or SunOne)
23. For C/C++ code CryptoAPI (CSP) will be used
24. For scripting, CAPICOM will be used
25. For Windows kernel mode, statically linked version of RSA32.LIB will be used."
26. The crypto algorithm being used will be easily replaceable. Hard coding is not being done. It is easy to upgrade the algorithms in the future.
27. If the user of the software does not specify it, strong algorithms are used by default. The software will not "automatically" fall back to a weak crypto.
28. If symmetric key-based cryptography will be used, then the CBC mode will be used.
29. If hash functions will be used, then the SHA-2 family of hash functions (SHA-256, SHA-384 or SHA-512) will be used.
30. The application will DP API (Data Protection API) to store secure data and passwords.
31. If the application requires random numbers, a strong quality random number generator will be used.
32. If a secret key is required to be generated from a user password, the user password should not be merely hashed. Instead a KDF (Key derivation function) should be used to derive a key from a password. (Eg. CryptDeriveKey on Windows)
33. Are cache-control : no-cache or cache-control : no-store used to prevent caching in browser?
34. Application caters if 128-bit SSL is not supported in the web browser.