There’s nothing more embarrassing for a web-based company than allowing their user’s personal data to be revealed on the open Internet. Websites and services have an ethical duty to protect the private data entrusted to them, and yet, time and again, we hear of hugely popular web services like LinkedIn and Last.fm engaged in password practices that are very definitely not the best.
On top of the ethical duty, there are significant costs associated with lax security, including danger to business continuity, loss of reputation, and legal consequences for failure to adhere to data protection regulations.
Security breaches are going to happen. Hackers are smart and there’s no such thing as perfect software, but there are steps that should be taken to ensure that in the event of password data getting out into the wild, it will be useless to identity thieves and other malicious parties. Here are 5 guidelines to follow to ensure that your users passwords remain safe.
Never Store Passwords in Plain Text
This should go without saying, but user’s passwords should never hit your disks in plain text. You might think your servers are secure, but so did everyone who stored their passwords this way and lost them.
Use a Cryptographically Secure Hashing Algorithm for Stored Passwords
Hash function (Photo credit: Wikipedia)
Ideally, no one should know your user’s passwords apart from them, not even you. A hash function will generate a fixed-size string that is stored in place of a plain text password. This string (hash value) is unique (or unique enough) that no other password is likely to generate an identical hash. It is mathematically impossible to reverse this operation. When a user enters their password, the hashing function is applied to it, and the result compared to the stored hash value. The plain text password is never stored anywhere. The MD5 hash function is no longer sufficient; SHA2 is a better option.
Salt Your Hashes
It is possible to reverse sufficiently simple hashed passwords using dictionary and brute force attacks, lookup tables, and rainbow tables. These methods are only feasible over a relatively small range of possible passwords, due to the impracticality of computing and storing the entire space of possible passwords, and a sufficiently long or random password is largely immune to this sort of attack. However, services cannot rely on users to choose such passwords, so a “salt” is generated before a password is hashed. A salt is a long, random, and, ideally, unique set of characters added to a password before hashing. Using a sufficiently good salt renders the available methods for hash reversal useless.
Encourage Users to Choose Secure Passwords
When users are choosing passwords, services should make it clear that simple dictionary-based passwords and short passwords are insecure, and encourage them to choose something more secure. Sites should also not limit either the length or the possible characters a password can contain. If passwords are being properly hashed and salted it doesn’t matter from a storage perspective what length they are or how they are constituted.
Do Not Attempt to Create Your Own Password Hashing and Storage Functions
No matter how expert a programmer you are, it is unlikely that you’re a cryptography expert. All the major programming languages contain solid, verified hashing algorithms that were created by experts and have been tested and examined by experts. Use them. It’s both a waste of time and a security vulnerability to try to produce your own.
Let us know in the comments or on Twitter what you think of the recent spate of leaked passwords, and feel free to add any suggestions of your own to help improve password security.
