How Much Security Is Enough?

How much security should be built into an authentication system to mitigate the risk of incorrectly identifying the subject of an authentication event, thereby enabling an attacker to impersonate an authorized user?  The answer, of course, depends on the risk tolerance of the services protected by the authentication system.

Appendix: Authentication Threats lists potential threats to an authentication event. Different authentication factors mitigate different threats to varying degrees. Multi-factor authentication combines multiple factors to mitigate a broader range of threats, but nothing is perfect. It is still necessary to accept some risk. How much risk can be tolerated depends on the value and risk associated with the assets being protected. Determination of value and risk is a management decision and can be informal or based on a formal risk assessment framework, such as OMB M-04-04 E-Authentication Guidance for Federal Agencies.

The following sections discuss typical scenarios for higher education and how multi-factor authentication can be applied to achieve appropriate risk mitigation. The scenarios are ordered from one involving minimal risk assessment of protected assets, to one involving risk assessment of selected assets, to one assuming a general security program that classifies assets' risk profiles and associates appropriate identity assurance profiles (of which authentication is a part) with each risk profile.

It may be tempting to treat this ordering of scenarios as a deployment road map, but this may not be desirable. While today's needs may match the first scenario, it may be more appropriate to deploy a solution that can be used for the second or third scenario at a later date, thereby avoiding multiple deployments.

Scenario 1: Augment Password Security

In this scenario, a second factor is introduced to mitigate the threats associated with passwords, particularly phishing, online guessing, and offline cracking. By introducing a second factor, simply learning someone's password does not constitute a successful attack. Some physical token or device (such as a cell phone) must also be obtained, greatly reducing the likelihood of a successful attack. This is probably the most common reason for implementing multi-factor authentication, and it has been embraced by large providers like Google and Facebook. The second factor is, most often, the user's smart phone, due to the relative low cost and ease of deployment

Just about any multi-factor solution will mitigate the threats of phishing, online guessing, and offline cracking.  If the goal of an MFA deployment is to regain confidence that has been lost in password only authentication schemes over the past few years, then the multi-factor solution(s) to be deployed can be chosen primarily on factors of ease of use, ease of deployment, and cost.

Scenario 2: Mitigate Authentication Risk for Specific Applications

In this scenario, multi-factor authentication is introduced to mitigate authentication threats for one or a small number of specific applications.  In higher education, this might be a student or medical information system or some other system containing data that is protected by law.  Tokens are issued to the users of these systems to provide a higher degree of confidence that people using the system are, in fact, authorized users.

Selection of a multi-factor solution for this scenario is heavily dependent on the specific applications involved. The solution must be able to interoperate with those applications in addition to mitigating the specific risks presented by those applications.

Scenario 3: Mitigate Authentication Risk for Classes of Applications

In this scenario, applications are classified according to their tolerance for authentication risk, and multi-factor solutions are introduced to mitigate the risks of each class, generally in conjunction with other controls for identity proofing, credential issuance, etc. Assurance frameworks, such as the InCommon Assurance Program and FICAM are examples of this.  Applications are classified according to a risk assessment framework like OMB M-04-04 E-Authentication Guidance for Federal Agencies, and identity providers are certified to provide identity assertions that comply with assurance profiles that are appropriate for the various classes of applications.  M-04-04, for example, provides the following mapping from an application's risk classification to an assurance profile.

Selection of multi-factor solutions to address the needs of these assurance profiles is heavily dependent on the requirements of the assurance profiles that are being addressed. Documents like NIST Special Publication 800-63-2 Electronic Authentication Guideline and FIPS 140-2 Security Requirements for Cryptographic Modules describe these requirements in great detail.

Appendix: Authentication Threats

NIST Special Publication 800-63-2 Electronic Authentication Guideline identifies several threats associated with authentication events. These include

• Theft. A physical token is stolen by an Attacker.
• Duplication. The responses to token prompts are easily discovered through searching various data sources.
• Discovery. The Subscriber’s token has been copied with or without his or her knowledge.
• Eavesdropping. The token secret or authenticator is revealed to the Attacker as the Subscriber is submitting the token to send over the network.
• Offline cracking. The token is exposed using analytical methods outside the authentication mechanism.
• Phishing. The token secret or authenticator is captured by fooling the Subscriber into thinking the Attacker is a Verifier or RP.
• Social engineering. The Attacker establishes a level of trust with a Subscriber in order to convince the Subscriber to reveal his or her token or token secret.
• Online guessing. The Attacker connects to the Verifier online and attempts to guess a valid token authenticator in the context of that Verifier.
• Replay. An attack in which the Attacker is able to replay previously captured messages (between a legitimate Claimant and a Verifier) to masquerade as that Claimant to the Verifier or vice versa.
• Session hijack. An attack in which the Attacker is able to insert himself or herself between a Claimant and a Verifier subsequent to a successful authentication exchange between the latter two parties. The Attacker is able to pose as a Subscriber to the Verifier or vice versa to control session data exchange. Sessions between the Claimant and the Relying Party can also be similarly compromised.
• Man-in-the-middle. An attack on the authentication protocol run in which the Attacker positions himself or herself in between the Claimant and Verifier so that he can intercept and alter data traveling between them.

Different authentication factors mitigate different threats to varying degrees. Multi-factor authentication combines multiple factors to mitigate a broader range of threats, but it is always necessary to accept some level of risk.