As it should be, account and password protection is a hot topic right now– and it hasn’t been taken lightly in the development of Softdocs’ next-generation enterprise content management and workflow solution, Etrieve. Read Softdocs Enterprise Architect Jamie Pearson’s breakdown of the account and password protection measures designed and integrated into Etrieve for the safety and security of Softdocs customers and their ultra-important data.
With the first release, Etrieve will support authenticating users with Active Directory, Active Directory Federation Services (ADFS), Etrieve accounts, Google accounts, Microsoft accounts and Facebook accounts. There is tremendous demand for single sign-on, so we expect most of our customers will opt to use Active Directory or ADFS to authenticate users. But we also understand there are situations where a customer may want to authenticate some users with Etrieve accounts. It is only in this last scenario that we will be storing user passwords. To keep the passwords safe from hackers, we must be careful in how we store them, and in what form. In this post, I want to share some of the considerations that went into ensuring we protect the passwords of users authenticated with Etrieve accounts.
If we have access controls in place, you might wonder what’s wrong with storing passwords in their original form—plain or clear text. If we did, anyone with access to the data could see them. Under normal circumstances, this includes anyone who manages the servers that host the application’s databases. And if a flaw were found that allowed a hacker to access data, the passwords would be fair game to them as well. Revealing the passwords would give these folks the ability to log in as any user. It might also provide clues about patterns users use to create their passwords and, potentially, make their accounts on other services vulnerable. The potential to unlock other services is a key objective of hackers because they can use those accounts to deceive a user’s contacts by pretending to be them, or even steal the user’s identity. So it is important that we store passwords in an encoded form, which hides the original value, regardless of other security measures that might be in place.
Since we don’t want to store passwords in plain text form, we need some way to scramble them into a form that makes them unrecognizable. One common form of scrambling is called encryption.
Encryption is a method of encoding information into a form that makes it unrecognizable. It’s similar to the decoder games you may have played as a kid, but the process has a mathematical foundation and is typically much more sophisticated. The goal of encryption is to encode the information to prevent unauthorized viewing while giving authorized viewers the ability to, at will, decode the scrambled information and see the original value—encryption is reversible.
Reversible encryption allows the original password value to be retrieved. This isn’t much better than storing passwords in plain text because a user with access to the key store—that administrator or hacker I mentioned earlier—can use the key to decode the scrambled password data and obtain the original value. Once they’ve done that, we’re right back in the situation we were with storing passwords in plain text.
On the surface, it sounds like encryption is exactly what we need for passwords; however, it is far from it. We really don’t want or need to recover a user’s original password value, so we need a method of scrambling the data that can’t be reversed. That’s called hashing.
Hashing is the preferred practice for protecting passwords. It is a form of encoding that converts information into something that is unrecognizable and the process cannot be reversed to obtain the original value. Aside from being non-reversible, hashing has other important characteristics that make it suitable for protecting passwords.
Hashing produces widely different values for even small changes in the original value. For example, using the MD5 hashing algorithm, password and Password produce two completely different values—5f4dcc3b5aa765d61d8327deb882cf99 and dc647eb65e6711e155375218212b3964 respectively—despite varying only by the case in the first character. It’s important to note that MD5 is used here for illustration only. It’s a poor choice for hashing passwords.
Hashing is also able to take a value of any length and produce a new value of a fixed length. For example, the paragraph above, when passed through the MD5 algorithm, produces a hash value of fc3726caf3f37ee8e15fe615e827805d—the same length as the hashes for “password” and “Password”. This gives us the flexibility to accept a password of any length without providing any clues to hackers about the length of the original value.
Finally, the best hashing algorithms strive to ensure that two input values never produce the same hash value.
Hashing alone isn’t enough to protect passwords. Looking back to the MD5 example, we can see that there is a one to one relationship between a value and its hash. While hackers cannot simply reverse it, they can use dictionaries—pre-computed hashes and their corresponding password values—or rainbow tables—shortcuts to computing dictionaries on the fly—to exploit this relationship in reverse to defeat hashing and discover the password values. To protect against the latter of those tactics—rainbow tables—we also need to salt the passwords before we hash them. Salting is the process of adding some unique, random information to the original value before sending it through the hashing function. Salting makes rainbow tables much less effective by dramatically increasing the computational resources needed to crack the passwords. This leaves hackers with dictionary and brute force (i.e. repeatedly guessing) attacks in their toolbox.
Using modern desktop hardware, popular hacker software can calculate the hashes of all combinations of six character passwords in about 40 seconds. Many hashing algorithms were designed to be fast—they were not security focused—or were security focused, but designed a decade or more ago—well before we had the cheap, powerful hardware of today. To defend against the nearly unfathomable speed at which today’s computers can calculate hashes, and the pace at which computers are getting faster, we need to make hashing more computationally intensive. And we need to be able to adjust the intensity, or work factor, over time. A well-designed password hashing algorithm is designed to be slow and allows us to increase the work factor to account for faster computer performance in the future. This helps with brute force attacks by reducing the number of hash calculations from billions per second to tens or hundreds of thousands per second.
Most of us have had to follow the recommended practice for creating a strong password—create a password that is at least eight characters and consists of a mix of uppercase letters, lowercase letters, numbers, and punctuation. This type of password policy is called a comprehensive8 password. Some recent research suggests that this password policy is hard for users to comply with and remember. Comprehensive8 passwords are also relatively easy for sophisticated password hacking tools to guess with offline brute force or dictionary attacks. Based on that research, some experts are recommending that users create longer passwords—16 or more characters in length—that consist of a random mix of words. The longer passwords—basic16 passwords—are easier for users to create and remember. They’re also more computationally intensive for computers to guess and the cracking tools are not as optimized for them.
So when accepting passwords, we want to give admins the flexibility of using a longer password policy such as basic16. We generally don’t want to impose any length or character restriction at all.
Etrieve’s password protection accounts for the challenges of securing user passwords by utilizing a salted hash that is designed to make password cracking computationally intensive and slow. To address the pace at which hardware speeds increase, the hashing algorithm also provides the ability to adjust the work factor in the future. Couple the hashing algorithm characteristics with the ability to leverage a longer password policy and we greatly increase the time a hacker must invest to recover a significant number of passwords.
When planning security, it is important to consider all possible scenarios. One of the worst scenarios for passwords is the loss of the password store. Once a hacker gains offline access to the password data, he or she can leverage fast, cheap hardware along with freely available cracking software to attempt recovery of the original password values. It is our goal to safeguard your passwords against this eventuality by using accepted industry and cryptographic security standards.