Insecure cryptographic storage.
To avoid problems:
- Encrypt sensitive data e.g. passwords, credit card details, health records and personal data. Do not write these to log files.
- Ensure strong encryption algorithms and strong keys are used.
- Use an open source or commercially available encryption or hashing library - do not create your own encryption or hashing algorithm or write your own code.
- Ensure offsite backups are encrypted, with the keys held and backed up separately.
- Ensure passwords are hashed with a strong algorithm, and salted.
Follow the Payment Card Industry guidelines for credit card processing.
Hashing passwords
There are many articles on the web suggesting that MD5 and SHA-1 are no
longer considered to be strong enough algorithms for hashing passwords.
In fact if you type an un-salted MD5 hashed password into Google, there
is a reasonable chance of finding the plain-text password.
Stronger hashing algorithms are available e.g. SHA512 or PBKDF2.
Here are some guidelines for dealing with passwords:
- Do not store any password in clear text (and remember that Base64 encoding is not encryption and is trivial to reverse).
- Store the passwords as secure one-way hashes so that they cannot be decrypted.
- Hash passwords on the server, not client.
- Use salt (see below) as this reduces the effectiveness of using rainbow tables to crack hashed passwords.
- Enforce a minimum password length of 10 characters, together with rules on upper-case letters, lower-case letters, numbers and special characters.
- Add a random time delay to the hashing process to reduce the effectiveness of any timing attack or profiling.
Some guidelines for using salt:
- Add a random salt that is unique for the user - this can be stored next to the hashed password, in the user table.
- Change the random salt when the user changes his or her password.
- Also add a system-wide salt when hashing. Do not store this in the user table - if your user table is copied, the attacker will still not know the system-wide salt.
- Consider adding part of the username as salt.
- The password changed date is normally stored in the user table (so that you know when to tell the user to change his or her password). Consider adding this to the salt.
Although you should always use an open source or commercially available hashing library and avoid writing your own code, changing the way you use the hashing library helps security. For example, you could add part of your salt to the password, use PBKDF2 to hash it, then add more salt, do more hashing etc. Normally "security through obscurity" is not considered to be good practice, but in this case the technique reduces the effectiveness of rainbow tables and so increases your security.
Some interesting links: