Within most web applications there is a need to store sensitive data such as passwords, credit cards, account records and other confidential information by encryption in files or databases. Even though encryption is no longer difficult to implement, yet often developers make mistakes concerning what items are encrypted and in how encryption is applied in an application. Often they overestimate the capability of encryption to keep data secure while neglecting to insure the security of other areas of an application. There are many areas where mistakes could be made including:
- The neglect to encrypt sensitive data.
- Storage of keys, certificates, and passwords in a non-secure fashion.
- Incorrect storing of confidential information in memory.
- Insufficient randomness of keys, tokens and cookies.
- Use of a weak encryption algorithm.
- Use of an unproven encryption algorithm.
- Lack of support for maintenance procedures and encryption key changes.
As a result, these omissions in cryptographic storage could be devastating for an organization as systems and sensitive assets become compromised.
Site and application vulnerabilities can be determined by checking for sufficient randomness in credentials (tokens, session IDs and cookies) and by utilizing code reviews for examining how cryptographic functions are implemented.
When it comes to preventing failures with cryptographic storage there are a number of items that can be addressed:
- Minimize the use of encryption.
- Encrypted any sensitive data that will be stored long term.
- Insure that only authorized users can access decrypted copies of the data.
- Insure that a strong encryption algorithm is used. (Approved public algorithms such as AES, RSA public key cryptography, for hashing use SHA-256 or better. Do not use weak algorithms, such as MD5 or SHA1.)
- Only use widely accepted implementations of cryptographic algorithms rather than implementing an algorithm on your own.
- Ensure that random numbers are cryptographically strong.
- Use only authenticated encryption modes.
- Store only the hashed and salted value of passwords
- Ensure that the cryptographic protection remains secure even if access controls fail.
- Ensure that core credentials such as database credentials are securely stored.
- Recognize that hashing is not the same as encryption and could be broke if the hashing method is known.
- Encrypted data should not be easily decrypted.
For the generation, storage and transmission of keys:
- Ensure that any secret key is protected from unauthorized access.
- Store unencrypted keys away from the encrypted data.
- Use independent keys when multiple keys are required.
- Protect keys in a key vault.
- Never transmit private keys over insecure channels.
- Plan for key changes; define a key life cycle.
- Formalize procedures for managing keys through their life cycle.
- Build support for changing keys periodically.
- Rekey data at least every one to three years.
- Create procedures to handle a key compromise.
- And follow applicable regulations on use of cryptography.
For more information see: