Quick Hits: Handling Secure Password Storage

The following post is a quick walkthrough on how to set up a secure password storing policy. In application security, it is very important to have a secure and reliable password storage policy. I hope you fine the following to be useful and maybe even implement it in your organization.

When designing an application, I would take a two sided approach when it comes to secure password storage. First, I would address the policy that users should follow to create passwords. Secondly, I would tackle which format passwords will be stored in.

From the application side, I would ensure that short or no-length passwords are not allowed to be stored. Second, encoding and character set restrictions on the entry/storage of credentials will not be allowed. While some organizations attempt to enforce character set and length restrictions to protect against SQL Injections and Cross-Site Scripting (XSS), it still allows for simple attacks such as brute force. Applications should utilize password policies that include 21 character minimum and a minimum requirement for use of multiple special characters and numbers.

Third, I would utilize a hashing and salting mechanism if storage allows for it. First off using hashing functions such as SHA-2 provides a level of security above storing a password as plaintext. Essentially, hashing functions are one-way mapping algorithms that cannot be reversed. Adding a salt (a random 8 bytes minimum string generated for each user who registers) and hashing it along with the user password can provide another layer of complexity for attackers to work against.

Therefore, utilizing a password policy and hashing/salting techniques will ensure that even if user data is exposed, extracting the passwords from it would be an insurmountable task.