How safe is your site's password management system?
Throughout the year, we've seen a number of large-scale data breaches affecting user passwords, such as eBay and Yahoo, and recently security researchers reported that 1.2 billion passwords were stolen by Russian cyber-criminals. With password breaches constantly making the news, it's led many to believe that the password system itself is fundamentally broken and must be replaced. Talk of a "post-password future" is at a fever pitch, with alternatives like biometrics and mobile-based authentication touted as the next big thing to protect users.
But is the password system really broken? In reality, the problem with passwords today is largely due to how they're managed by applications. The password remains one of the most effective and convenient methods for users to protect their accounts and for sites to verify their authenticity - just because poor implementation has created the opportunity for breaches, doesn't mean this issue can't be resolved directly by developers.
Here are six things developers can do to ensure the safety of passwords in their applications:
- Make Someone Else Deal With Them - Why handle passwords at all when you don't have to? If you prefer to not have your site or application shoulder the responsibility of managing a high integrity password system, shift the burden to an already established protocol like OpenID or Facebook Connect. By acting as a relying party, you can develop your application without having to deal with the fuss of password storage and maintenance. Instead, you can leave this heavy lifting to the identity provider. However, make sure you use only trusted identity providers with solid track records of security, as they will have the keys to issue or forge tokens for any user.
- Force User Best Practices - Another simple way to improve password security is by denying users the ability to use bad passwords. Require all users to select strong, complex passwords that will be more challenging for attackers to guess. For instance, passwords should be 10+ characters long, involve upper and lower case letters, and include numbers and special symbols (@%*, etc.). You could also require users to change passwords on a regular schedule and include password best practice tips on the registration page. Of course, this won't prevent users from reusing passwords from other sites and it won't always protect against sophisticated attacks like brute-forcing, but it will raise the site's security threshold.
- Store Password Hashes, Not Passwords - Using a hash function enables a site to authenticate users without having to store their actual passwords. As operating system designers have known for a long time, the proper method for storing credentials is to do so in a non-reversible fashion. When storing hashes, use a random salt of sufficient length and entropy to make brute-forcing/hash-cracking attacks more difficult, even against weak passwords. Salts are clear-text values stored with the hashed password. They are appended to the password before hashing to make each resulting hash require a unique cracking attempt and prevent rainbow table usage. Another tip: use a second salt that is hardcoded or configurable into the hashing routine. Since this salt is stored independent of the database or file that contains the password hashes, a compromise of just the hash storage will not enable an attacker to feasibly crack the hashes unless they obtain the second salt as well.
- Multi-Factor Authentication - Without a doubt, MFA is the simplest way for developers to prevent account takeovers after a password breach. And every site or application should offer MFA as an option to its users. The problem, however, is that while MFA can be simple for the developer to implement, it is often viewed as inconvenient for the user. To overcome this obstacle, developers may want to consider a hybrid approach: i.e., only require a second form of authentication for specific situations, such as when changing account details like the password or when logging in from a new computer or device. A hybrid approach to MFA is not as effective as pure MFA, but it does help.
- Use a Challenge/Response Protocol - For web applications, this is probably a non-starter, but for mobile applications and thick-client applications that have code running on the user's system, a challenge/response protocol allows your application to verify user identity without ever holding the user's password. In formal terms, this is called a Salted Challenger Response Authentication Method and works hand in hand with #3.
- Safely Storing Passwords - If you absolutely must store user passwords directly, take several steps to protect them. First, use a strong block cipher with random initialization vector (equivalent of a seed) of proper length. This length will depend on the crypto algorithm and key size. Just about every platform offers an appropriate block cipher, but the most commonly used cryptographic libraries are BCrypt on Windows and OpenSSL on Unix and most other platforms. In terms of cipher, developers should use a 128bit AES at a minimum with 256bit or greater preferred. Do not store the encryption key(s) with the passwords. Admittedly, storage of the key is a hard problem. On Windows you can use techniques like DPAPI. On Unix, some kind of keystore can be used. For high security implementations an HSM (Hardware Security Module) should be used.