Over the past year or so, we've been seeing a new twist on the old "human factors" vector for attacking online systems. A "human factors" attack is one in which an attacker deceives a person in order to get that person to give the attacker access to an account or privileged information. In this scenario, a human—not a computer system—is the weak link in the security chain.
What's interesting about the latest attacks such as those executed against Twitter users @N and @mat is that the human factors attack is just one part of a larger puzzle. The interesting element here is that information or access gained from a human factors attack on one system is used as the basis for a subsequent attack on another system. In other words, the security of the weakest web site to which a user has access ends up defining the overall security for many of the systems to which they have access.
As a builder of an online system, you can easily provide your users with the proper tools to protect them from these kinds of attacks. In short, your job is:
- to establish a system so that a compromise of other web sites does not weaken the security of your web site
- to make sure that a compromise of the user's account on your web site does not put their other online accounts at risk
While you may think of your processes as first class, the reality is that a common factor in many of these attacks is a minimum wage employee not following established phone support processes. Even the most security-conscious organization can (and does) fall prey to these kinds of attacks. You definitely don't want the security of your site weakened by the minimum wage employees of "Joe's Free Social Network Startup" and you don't want the information you provide through your online systems to be usable in engineering a human factors attack against other web sites.
Here's a list of 10 steps you can take to arm your users to protect themselves against these kinds of attacks.
Part I: Standard Authentication
Everything starts with proper authentication—making sure you know who is access your system. Unfortunately, a lot of online sites still get this basic component wrong.
Step 1: Allow long passwords that may contain any UTF-8 character
It's almost criminal how many web sites limit the number of characters in a password to less than 20 characters (in some cases, even less than 10 characters). Similarly, so many web sites—most specifically banks—limit the set of characters that may be in a password to letters and numbers. While there are great reasons to require a minimum password strength, there's absolutely no reason to limit the strength of user passwords.
Though I'm focusing in this article on remote attacks, I'd be remiss in not adding this: never store passwords in plaintext, and always encrypt those passwords using a user-specific salt independent of the password choice.
Step 2: Be friendly to password managers
This step may be the easiest to follow as you actually have to go to special lengths to be hostile to password managers. A password manager is a tool like 1Password that enables users to store all passwords for all web sites and other systems requiring authentication. When a user leverages a password management system, they are less likely to use the same password across multiple web sites and more likely to use very strong passwords.
A great example of a company hostile to password managers is Apple. They are constantly and needlessly requesting passwords from inside native applications, sometimes in contexts which prevent copy and paste. If you absolutely must place authentication around each individual transaction, have a separate, weaker transaction authentication system. It could be a PIN or it could leverage the existing second factor (see Step 3). The password is protecting the integrity of the entire system. That same strength simply isn't necessary to protect the integrity of every single transaction—especially if you are sending notifications around those transactions (See Step 5).
The other challenge for password managers is the foolish practice of preventing copy and paste of passwords. I've never understood this practice, but some web sites actively prevent you from pasting data into the password field. I suppose it's to discourage the passwords existing locally in memory, but if that's why, it's way, way off the chart on realistic attack vectors.
Step 3: Support multi-factor authentication
Multi-factor authentication is leveraging more than a single factor over distinct channels in the authentication process. Most commonly this comes in the form of two-factor authentication that consists of "a thing you know" (password) combined with "a thing you have" (a mobile device), both of which are unique to you alone. When implemented properly, it's very difficult for an attacker to compromise both factors.
While there are valid reasons for not requiring multi-factor/two-factor (MFA/2FA) authentication, there's never a valid rationale for not enabling users to leverage it. Every web site should give their users the option to enable some form of MFA. The most common implementation is sending a one-time token across the cellular network via SMS that the user enters as part of the authentication process.
There are a number of non-intrusive ways to implement 2FA appropriate to the security and usability needs of your web site. It could be requiring a second factor for every single login, or it could be just for new logins in a 30-day window on a "per-device" basis. You might also use it to authenticate particularly sensitive transactions.
One other note: picture-based anti-phishing techniques like PassMark are not second factors for authentication. In fact, they aren't any kind of authentication factor.
Step 4: Provide a voice backup process or recovery code
If you are using mobile devices for 2FA, you'll run into the reality that people sometimes lose their phones or lose control over their mobile number. If 2FA is turned on and you don't have a backup to 2FA, you risk permanently locking the user out.
The best option is a voice backup process. A voice backup process will enable the user to specify a voice phone number as a backup to the mobile second factor. In the event they lose their mobile device, they can receive an automated phone call on their home or office phone with the second factor.
An alternative is providing a one-time recovery key that the user can store (ideally, in a password manager) when they enable 2FA. If they lose their mobile device, they can request access using the recovery password as a one-time second factor.
Step 5: Send notifications every time a change is made or a backup authentication process is used
Attackers rely on their being a gap between the time an account is exploited and the time at which the victim notices it. You should therefore do your best to make sure any unusual activity comes to the attention of the user owning the account. To be successful here, you need to balance the number of notifications you are sending (you don't want users to start ignoring these notifications) with the need to keep the user informed. Typically the best thing to do is send a notification any time security-sensitive information changes or an attempt is made to use the backup authentication processes, backup second factors, or password recovery processes. I have mixed feelings about notifying a user every time an authentication occurs by a new device.
Step 6: Allow the user to specify separate email addresses for security sensitive messaging versus standard application messaging
Web sites typically identify a user through their email address under the reasonable assumption that the email address is publicly available information. In addition, web sites—in particular, social media sites—need to enable one user to find other users and email address is a great way to support that.
If the public email address is the only option your support, however, you create a number of a security problems.
- You increase the likelihood that users will ignore security-sensitive notifications like those described in Step 4.
- You reduce the security of the user's account down to the weaker of the security of their email provider or DNS provider.
- Attackers can easily guess public email addresses and use them to orchestrate both human factors and other kinds of attacks.
Knowledge of a user's public email address was a critical element to both the @mat and @N attacks.
An easy way around this is for a user to have a "private" email address they use for security-related activities. If a user has one of these emails and you support it, you will find these users pay close attention to the security-related notifications you send. It also greatly increases the complexity of infrastructural attacks on DNS and email providers that attackers will use to circumvent your notifications systems.
A private "security" email address is also useful in online password recovery processes. In addition to general security messaging going to the private email address, any attempt to reset a password via email-based password reset processes goes through the private email address for recovery purposes.
Part II: The Password Reset Process
All of these attacks start with the password reset process. The integrity of your authentication processes doesn't stop with how you handle the standard authentication. It includes your password reset processes. If you ask security questions using information readily available on social network sites, then that's the same as asking "What was your first school?" instead of requiring a password.
A password reset process exists because there are valid scenarios in which people forget/lose their passwords. Your objective here is to find alternate mechanisms for a user to prove that they are who they claim to be so that you prevent them from getting locked out of their account. A good password reset process thus is a stronger authentication system than the standard authentication process, but not so strong that it's ever likely to lock a user out of their account.
The authentication behind password reset processes is necessarily less user-friendly than password-based authentication. If it were as secure (or more secure) and easier to use than password authentication, we'd be using that for regular authentication, wouldn't we? SO STOP TRYING TO MAKE "USER-FRIENDLY" PASSWORD RESET AUTHENTICATION SYSTEMS. FOCUS ON MAKING DAMN SURE THE PERSON IS WHO THEY CLAIM TO BE.
Step 7: Abandon security questions in the password reset process
I've never encountered a password reset methodology based on "security questions" that didn't simply act as an end-around the password authentication system. The basic problem with security questions is that they ultimately all involve information available on other web sites. That information may come in the form the kind of data you'd find in someone's Facebook profile. It could even be "private" information like social security number. Nevertheless, if it's good for your site, it's good for another site. While the problems with Facebook profile questions should be obvious, even "private" information could become available to an attacker if that attacker gains access to another account held by the user in question. You've thus just weakened your web site's security to be as bad as the weakest site on which the user has an account—or a forgotten account—simply because data is common between the two sites' security questions.
Another problem with security questions is that the answers to those questions can often vary in time. Consider, for example, "What is your favorite color?". That may change over time. I'm then presented with this security question and I have to remember what my favorite color was at the time I created the account. A side issue is that spelling becomes a problem. I actually spell the name of my first pet several different ways. Sites that use this question for security purposes infuriate me because I can never remember which way I spelled my first pet's name for that particular account.
Step 8: Never use common data for any user authentication processes
This step is a more general formulation of the first step. The attack on @mat, for example, leveraged the fact that Apple used the last four digits from the user's credit card in its phone-based user authentication processes. Of course, any ecommerce site is likely to hold at least the last four digits of the user's credit card. Consequently, @mat's Apple ID was only as strong as the weakest ecommerce site storing his credit card data.
There are two critical points here:
- This rule applies to all modes of alternative authentication, whether automated online or manual via the phone.
- The data used in these processes is often considered "private" data. The weakness here isn't in the private/public aspect of the data, but instead of the fact that the data may ever be available to another company.
Step 9: Allow users to disable any kind of phone-based password reset.
For people who do a good job with their online security, phone-based password resets are a crutch they almost certainly don't need, yet its existence reduces the user's overall security. Let these users indicate on their profile that phone-based password resets should not be allowed.
By phone-based password reset, I mean the "a support desk person asks a few questions and resets the password or sends out a reset through email" thing. You need some kind of manual process, but users should be able to indicate they want to be forced to go through a "last resort" process involving empowered management and strict proof hurdles rather than the typical front-line support asking for basic information.
Step 10: There must be a strict "last resort" manual process.
One of the things some attacks rely on is an ability to secure your compromised account against you so that you are permanently locked out of it. This happens only because web sites are too damn lazy to support a "last resort" process. Approaches to a last resort process may include physically presenting yourself or presenting notarized credentials (such as a notarized copy of a birth certificate or driver's license) to managerial decision makers. The nature of the approach you take will depend on the infrastructure available to you. There are two key elements that must be in place:
- What is authenticating the user should be something that a government agency would accept as proof of identity.
- The person making the authentication decision should be someone who can truly be held accountable for a bad decision. In other words, it should not be a minimum-wage employee who barely cares about losing their job.