It is disappointing to hear news about large organisations or popular applications having security breaches. What’s much more disappointing is how often it’s their own fault for not following even basic security practices. There have been a few recent incidents that have sparked this post, but even before these big screw ups occurred, I was personally quite interested in what good data security is about, in particular user data. We'll be taking payments so security is an even bigger focus for us here at Picnic, but in this post I wanted to keep the discussion focussed on user data, in particular passwords.
The recent incidents are quite upsetting to software professionals who take pride in producing quality software solutions, when it gets discovered that companies that should know better have made a big mistake in how they went about storing something as important as passwords it's not acceptable. When I say companies that should know better this is basically any company that is producing software that their customers will use.
- June 2012
- July 2012
There is a wealth of information out there and many people willing to share their knowledge of what steps must absolutely be taken to process and store passwords. Character set or length limitations are absolutely a mistake. I can understand it is often related to legacy systems that had hard storage limits, but realistically the large organisations who are guilty of password character restrictions and length limits should be taking steps to update this as a priority. Heading towards what is now obviously the correct way to store passwords.
The companies who can retrieve your password and deliver it plain text clearly haven't invested in any real security around user data, and are the worst offenders. Plain text password retrieval should never be an option, everyone should be able to appreciate how easy an email feed-back loop for a password reset is, it can be triggered by the user, or on the users behalf, even in a pre-pre-alpha product it's not difficult to send users a link to reset their password.
Some very simple tips
Great security is hard, and does deserve focus and attention, the easiest part is getting started in a direction for comprehensive security practices.
Here’s a basic summary of best practices and some links.
There are many other concerns that go beyond the scope of what I want to discuss here, such as physical security, hardening the infrastructure against attack, etc. If the data does eventually leak / get stolen, you want to ensure it will be time consuming for it to be exploited via an offline brute force attack.
This is why long secure and not re-used salts are so important. Having a salt added to the password reduces the ability to use precomputed hashes i.e. rainbow tables. The current recommendation is to have a salt length of at least 64 bits.
The right direction for strong security boils down these main elements:
- Up To Date:
- Using good cryptographic means.
- Password hashing through multiple iterations.
- At the time of writing SHA512 for hashing is quite suitable
- No Limits:
- Taking and encouraging long detailed passwords from users
- Not forcing passwords to start with a letter
- Salt + Hash:
- Hashing is a must, an encrypted password means it can be decrypted.
- Hashing those passwords combined with a per user cryptographically random salt.
- Do NOT reuse salts
A very common tip is also to never "home brew" your own hashing mechanism, for a variety of reasons most of all you're not a cryptography expert.
- Key Stretching
- Securing against brute force attacks by increasing the time it takes to test each possible key.
- A cryptographic method of key streching.
- A set of has functions, such as SHA-512.
- C# implementation using SHA-2 and iterations to hash a password.
- PBKDF2 (Rfc2898DeriveBytes) implementation in C# from StackExchange set of sites code base.
- Note: the code I'll be covering in the follow up post will be along those lines.
General crypto, encryption and hash discussions
- Why NOT to combine hash algorithms.
- Which hash should I use?
- Generating a key from a password.
- HMACS encryption in .NET.
- PBKDF2 discussion.
- Insecure Cryptographic Storage.
Here at Picnic from day 1 of writing this application we have done our due diligence to review what the industry is discussing in terms of hashing passwords securely and other security related concerns.
In a soon to come post, I’ll be sharing some of the mechanisms we’re using that are particular to the .NET world.