Within the last week, LinkedIn, eHarmony, and Last.fm have all announced security breaches that resulted in millions of user passwords exposed to the world. While the passwords were encoded with one-way digests, that didn’t stop attackers from discovering the clear-text passwords for a large percentage of those accounts.

There’s no such thing as a perfectly secure system, and brilliant and determined hackers have a lot of tricks up their sleeve, from technical assaults like exploiting unpatched software vulnerabilities and to social engineering cons like sweet-talking secretaries. But there are a lot of things that LinkedIn and the others should have done to help prevent this kind of breach.

Consider Using Third-Party Authentication

The best way to ensure that attackers can’t break into your system and steal user passwords is for your system to not have any user passwords. Authentication systems like OpenID and OAuth allow you to push the responsibility for authenticating users (and securing their accounts) to a third party. If you’re willing to leave the authentication to an organization like Google, Facebook, or Yahoo, and your users are willing to accept this solution, then you don’t need to worry about storing credentials at all.

Note, however, that passwords may not be the only sensitive information that you need to store in your system. In fact, attackers generally don’t care about user passwords themselves but rather the other information about users that passwords can be used to access. As a result, you should treat all the information that you store about users with the utmost care and sensitivity because any compromise of your system will be bad for both your users and your reputation, regardless of whether that compromise includes login credentials.

It is therefore important that you store your data in a repository that offers the kinds of security features you need to help ensure it is adequately protected. The UnboundID Directory Server offers a wide range of security features, including several that you won’t be able to find in other products. Some of these features are primarily intended to help secure user passwords, but many can be applied for all kinds of information.

Use Salted Password Hashes

The people who designed the security systems at these companies knew enough to use cryptographic digests (also called hashing algorithms) to protect the passwords. These are mathematical algorithms that transform passwords in a way that is believed to be impossible to reverse. Good cryptographic digests (like the SHA-1 algorithm used by LinkedIn) offer a good level of protection because they prevent attackers from knowing useful information like how long a password is or what kinds of characters it might contain, and if they’re guessing passwords then they won’t be able to tell how close any guess is to being right.

But one of LinkedIn’s big mistakes is that they didn’t salt their passwords. One-way digest algorithms always generate exactly the same hash for a given input. This is essential for their use in applications like protecting passwords and verifying data integrity, but it also means that attackers can (and do) prepare ahead of time. I may not be able to look at the string “6367c48dd193d56ea7b0baad25b19455e529f5ee” and know that it’s the SHA-1 digest for the string “abc123”, but if I have a big dictionary of commonly-used passwords, I can just run each of the strings in that dictionary through the SHA-1 digest in order to get the encoded representation, and when I find an encoded password that looks like “6367c48dd193d56ea7b0baad25b19455e529f5ee”, I can use my precomputed dictionary to do a reverse lookup and know that represents the password “abc123”.

Password salting prevents this kind of attack because it adds a random element into each encoded password. When you’re going to create a salted password, you first come up with some random data (for example, “kMPsCwaT”) and prepend it to the clear-text password (like “kMPsCwaTabc123”). Then, you run that through the digest algorithm (to get a hash like “51c4125fe2e2e94bdefa8f7a8e5c12ebfd94833b”), and finally prepend the salt to the hash (e.g., “kMPsCwaT51c4125fe2e2e94bdefa8f7a8e5c12ebfd94833b”). When a user is authenticating, it then becomes necessary to pull the salt off the encoded password and prepend that to the clear-text password that they provide before running it through the digest algorithm.

Because salted passwords contain random data, it’s not possible for an attacker to have a dictionary prepared in advance. Running through a dictionary (or using a brute-force approach to try every possible combination of characters) will take a lot longer to crack a password, and even if you are successful for one user, that won’t help for any other user even if they chose the same password because it will have a different salt and therefore a different encoded representation.

The UnboundID Directory Server supports password salting out of the box in a manner that is completely transparent to clients. It can be used in conjunction with MD5, SHA-1, and any of the 256-bit, 384-bit, and 512-bit SHA-2 variants. It’s on by default, and would have made it a lot harder (or at least taken a lot longer) for attackers to discover the clear-text representations of the stolen passwords.

Use Expensive Encoding Algorithms

If someone gets access to an encoded password and knows how it was encoded, then there really is no way to prevent them from discovering the clear-text password used to generate that hash. If they want it bad enough, they can simply try every possible combination of characters, and with relatively cheap access to distributed computing, it’s possible to generate trillions of hashes per second. The only variables that affect this are the strength of the password (as will be discussed below), and the algorithm used to generate its encoded representation. For example, using the 512-bit SHA-2 instead of the 160-bit SHA-1 just about doubles the length of time required to generate a digest, which in turn means that it just about doubles the length of time an attacker will have to spend trying to crack a password.

To make the process even more expensive, you can have your password encoding process use multiple rounds of hashing. For example, take the clear-text password, salt it, and run that through the digest algorithm. Then take the resulting hash and run it through the digest algorithm again. And again. Repeat this process so that the final encoded password requires 5000 hashes. If you’re using 512-bit SHA-2, then this process is now about ten thousand times more expensive than the simple SHA-1 process used for the leaked passwords, meaning that it will take an attacker ten thousand times longer to crack a password with this encoding scheme than with SHA-1.

The UnboundID Directory Server provides support for password encoding algorithms that employ thousands (or potentially even millions, if you’re really paranoid) of rounds of hashing using the 256-bit or 512-bit SHA-2 algorithms. This algorithm is already available for use in holding login passwords for many Linux and UNIX systems, so it’s been designed by and carefully scrutinized by many security experts and is considered extremely strong.

Reject Weak Passwords

If an attacker obtains an encoded password, then the biggest risk of that password being cracked comes from the strength of the password itself. A password that is a word from the dictionary or a name or date or other common string will almost certainly be broken in a fraction of a second. If a password is relatively short, then so also will be the time required to discover it even if it’s necessary to try every possible combination of characters. For example, if a beefy system can generate 100 billion hashes per second, then it will only take about two seconds to try every possible combination of eight lowercase ASCII letters.

The two biggest factors in password complexity are the length of the password and the set of possible characters it may contain (which we’ll call the password alphabet), and they’re related by the mathematical formula a^l, where a represents the size of the password alphabet and l is the length of the password. For example, if the alphabet is the set of lowercase ASCII letters and the length is eight characters, then there are 26⁸ = 208,827,064,576 possible password combinations (which seems like a big number, until you realize how fast computers are at performing these computations). However, if you instead consider both uppercase and lowercase letters, numeric digits, and a number of symbols, then the alphabet can grow to about 95 characters, and there would then be 95⁸ = 6,634,204,312,890,625 possible values, which is nearly 32,000 times larger and would take the better part of a day to crack on a system capable of trying a hundred billion passwords per second. And increasing the length to ten characters takes the time to crack from a little over eighteen hours to a little over eighteen years.

The best way to ensure that users have strong passwords is to configure your system to enforce restrictions around password length, the kinds of characters that may be used, and other kinds of constraints. The UnboundID Directory Server ships with support for a number of password validators, including:

• A dictionary validator, which can be used to ensure that users aren’t allowed to supply passwords that exist in a given dictionary file (optionally including testing the reversed password).
• A length validator, which can be used to ensure that users aren’t allowed to choose a password that is too short (or potentially too long, although there’s little reason to configure a maximum length).
• A character set validator, which can be used to ensure that passwords include at least a specified minimum number of characters from a number of different character sets.
• A unique characters validator, which can be used to ensure that passwords contain at least a specified number of different characters.
• A repeated characters validator, which can be used to ensure that passwords don’t contain repeated strings.
• An attribute value validator, which can be used to ensure that the supplied password does not match the value of any other attribute in the user’s entry.
• A regular expression validator, which can be used to ensure that the supplied password matches (or alternately, does not match) a given regular expression.
• A similarity validator, which can be used to ensure that when a user is changing his or her password, the new password is not too similar to the previous password.

In addition, the UnboundID Server SDK can be used to develop additional custom password validators if those provided with the server by default are not sufficient. It also provides a password history feature that can prevent users from repeatedly using the same set of passwords.

When allowing users to choose their passwords, it is also important to ensure that those passwords are always supplied in clear-text. Some systems allow users to provide the password in a form that is already encoded in a manner that the server can interpret. This is undesirable, because if a user is allowed to supply a pre-encoded password, then the server has no idea what the clear-text representation is, and therefore cannot determine whether it satisfies all of the configured password quality requirements.

Of course, strong passwords aren’t much good if users can’t remember them. This is a very real problem that needs to be considered, and it is compounded by the fact that your users will likely need to have accounts in other systems. In reality, this means that users will probably choose one of the following options:

• They will use a password manager that automatically keeps track of all the usernames and passwords they use across all systems they access. This is the best solution, and one that you should probably recommend, since it means that they only have to remember one password for the password manager, and let it remember all the others. Unfortunately, less experienced users may find this prospect kind of scary.
• Write their passwords down or keep them in a file. This is kind of the low-tech version of a password manager, and as long as all copies of the password list is protected, then it’s reasonably safe.
• Use the same password (or a small set of passwords) for all sites they access. This is dangerous, because if their password is compromised on one site, then it may be used to gain access to other sites. There’s not much that can be done to prevent this (other than requiring multifactor authentication), but unless it’s an account that has elevated privileges, it will be more likely to adversely affect that one user than the overall security of your data store.
• Forget the password they chose and rely on the “I forgot my password” mechanism to reset it each time they need to access your system. If the reset process is automated and requires them to receive an e-mail or SMS message, then it may be a relatively secure approach (assuming that the e-mail address and/or phone number were previously verified), but if it involves talking to a human then it will probably raise your support costs and may allow a skilled social engineer to convince the support personnel to grant them access to someone else’s account.

It is unfortunate that non-technical users will be the ones who find strong password requirements to be the most onerous and unpleasant, but it is important to decide whether end user convenience is more important than end user security.

Prevent Online Access to Passwords

While it isn’t clear exactly how the attackers were able to obtain these large lists of encoded passwords, it’s likely that they were able to manipulating the identity store (or an application using it) into performing a query that exposed this information to the requester. For example, if they were using a relational database, then maybe they discovered a flaw in an application that allowed for an SQL injection.

Identity data stores (whether relational databases, LDAP directory servers, or some other kind of repository) should be like roach motels for passwords: passwords can go in, but they can’t come out. It shouldn’t be possible for even an all-powerful user to perform a query that can retrieve password information, and the system should also require that all passwords supplied to it (whether validating credentials during authentication or supplying a new password) be processed over a secure communication channel so that anyone with the ability to observe the network traffic cannot examine it in order to learn passwords.

The UnboundID Directory Server includes a sensitive attributes feature that makes it possible do exactly this for passwords and other kinds of sensitive information. You can easily configure the server so that passwords will be stripped from results even for requests from root users, and to require that any operations attempting to manipulate the values of such attributes will be allowed only over a secure connection. It is possible to configure this restriction to be in effect across the server, but it is also possible to tailor the behavior to the requester (based on a number of characteristics, like who’s asking, how they’re authenticated, where they’re coming from, whether the connection is secure, etc.), so that if there is an application that does have a legitimate need to be able to retrieve this information, the server can be configured to only return the data to that application.

The UnboundID Directory Server also includes very powerful and flexible logging capabilities, and it is possible to configure the server to log information about any operation in which passwords (or other attributes which may contain sensitive data) is returned to the client. This can be useful for auditing purposes so that if an attacker is somehow able to issue a query that returns sensitive information, you can see exactly which entries and which attributes were accessed.

Encrypt Server Data, Including Backups and Data Exports

Even if they weren’t able to get the data store to expose the passwords via a network request, it’s possible that they were able to get the password data in some other way. For example, if they were able to obtain access to the system on which the data was stored, then perhaps they were able to examine the database files directly, or perhaps they were able to obtain a backup or export of the data that included passwords.

It is important to ensure that adequate protection is in place for all copies of the server data, whether on the live running system or in backups. Certainly this includes things like restricting access to systems which can access this information and ensuring that only authorized users are able to access the data files, but it is also recommended that you encrypt such information so that even if an attacker does gain access to it, they won’t be able to extract anything useful from it.

The UnboundID Directory Server makes it easy to enable encryption for all data so that it is never stored in the clear. It also provides the ability to encrypt backups and LDIF exports so that the information is protected in these forms as well.

Prevent Repeated Authentication Attempts

If you have adequately protected your system to prevent retrieving passwords from the data store, and if all copies of the data are encrypted, then attackers should be prevented from obtaining encoded passwords for users. However, there may be other ways to crack user passwords. The most common of these approaches is simply to try to repeatedly authenticate as that user with different passwords until you finally get it right. This will be much slower than the offline attacks that are available with access to encoded passwords, but given enough time, determination, and luck, it may just work. Of course, these kinds of attacks can be thwarted by limiting the number of unsuccessful authentication attempts that will be allowed for a user account before that account is locked.

The UnboundID Directory Server can be configured to lock accounts after too many authentication failures so that any subsequent attempts will fail even if the right credentials are given. This lockout can be either temporary (so that additional login attempts will be allowed after a specified period of time) or permanent (so that the user will not be allowed to authenticate at all until an administrator resets the password). It can also be configured to log and/or notify administrators when an account is locked as a result of failures, along with a number of other significant password policy events.

Enforce Authentication Restrictions

In many environments, it is common for each application to have its own account that will be used to perform operations in the server, and that application account may have more rights than normal user accounts. If an attacker is able to compromise an application account, then he or she may be able to wreak more havoc than with other user accounts.

To help prevent this, it is advisable to restrict application accounts so that they are less likely to be useful to attackers even if their credentials are discovered. For example, you may want to restrict their use to a certain range of IP addresses and/or to only allow them to authenticate in certain ways. The UnboundID Directory Server provides a number of features like this, including restrictions based on client address, authentication type, and communication security, as well as restrictions around the use of proxied authorization. In addition, client connection policies can also be used to permit or restrict operations based on a number of characteristics about the client.

Support Multifactor Authentication

One great way to mitigate the risk of compromised passwords is to make use of multifactor authentication, which require the user to provide multiple pieces of information to confirm his or her identity. This is usually manifest as two-factor authentication combining something you know (like a password) with something you have (e.g., some kind of device capable of generating one-time passwords or PINs). In a system that uses multifactor authentication, if an attacker discovers a user’s password, then they won’t be able to do anything with it unless they also have a way of obtaining the other credentials.

Multifactor authentication used to be a rather inconvenient prospect because it required that you actually provide your users with a physical device like a SecurID token (which has a numeric display with numbers that change every minute), and if you didn’t have that token with you, then you couldn’t authenticate. However, the proliferation of mobile phones has made this a much more realistic possibility. For example, you can configure your Google account to require multifactor authentication, combining a password with a one-time code obtained in one of the following ways:

Using the Google Authenticator app, which uses the time-based one-time password (TOTP) algorithm defined in RFC 6238. This option does not require any kind of network communication.
By having a one-time password sent to your mobile phone as a text message.
By having a one-time password read to you by a speech synthesizer over a voice call.

With multifactor authentication support enabled, an attacker will need to get access to your mobile phone in addition to figuring out your password before they’ll be able to access your Google account.

Similarly, Facebook can be configured to require a one-time code sent as an SMS message any time you log in from a system it doesn’t recognize. There are a number of other applications which provide some level of support for multifactor authentication, but it’s unfortunate that there are still so many who do not offer it as an option so that their more technical and security-conscious users can take advantage of the additional security that it can provide.

At present, the UnboundID Directory Server supports multifactor authentication in the form of a password combined with a PIN generated using the TOTP algorithm (and is therefore compatible with the Google Authenticator app, along with other software capable of generating these codes). However, support for additional multifactor authentication schemes may be added in the future.

Plan for Disaster

No matter how tightly locked down your system may be, you should have a plan for dealing with a security breach in which an attacker is able to successfully obtain passwords and/or other sensitive information from your system. Hopefully you’ll never have to put this plan into action, but it’s far better to have a strategy you may not use than to find yourself without one when you really need it.

The first thing that you should do is to identify what information may have been compromised, and then tell your users about it. Trying to cover it up may be illegal, and it prevents affected users from trying to mitigate the risk of the attack while giving the bad guys more time to use the data they stole. It will also likely be more damaging to your reputation if users hear about a breach in your systems from someone else before they hear it from you.

If information about passwords may have been exposed, regardless of whether the passwords were encoded, then you should encourage or require users to change their passwords as soon as possible (and the UnboundID Directory Server offers a feature that can be used to require users to change their passwords by a given date/time). However, you should also assume that if login credentials were obtained, an attacker could have authenticated using those credentials and obtained access to other information about the account.

You should also try to determine how the attack was conducted so that you can make any changes in your system to help prevent the attack from recurring. If there isn’t enough information available to determine the attack vector, then you may need to make broad changes to tighten the overall security of the environment. You will likely also want to ensure that appropriate logging is in place to make it easier to discover and analyze attacks in the future.

Finally, you should work with the vendors of any software that attackers were able to breach so that they can better understand how their software is being targeted and identify whether any changes may be needed to help prevent future problems. Even if the software you’re using has features which could have prevented the attack from succeeding, the vendor may wish to consider enabling those features by default or better highlighting them in their documentation. Certainly we at UnboundID would be very interested to hear of attacks (whether successful or not) against our software so that we can continue to reevaluate the product features and default configuration. And if you have suggestions for improvement, we’d love to hear them as well.