When Should You Use Two-Factor Authentication?

TL;DR

Use multi-factor authentication only when a transaction warrants greater confidence, such as when a banking customer adds a wire recipient. This risk-based trust elevation approach preserves stronger identification for sensitive actions while reducing unnecessary user friction, and centralized policies can help it scale across many applications through an architecture built around policy decision and enforcement points.

Transcript

Hi, everyone. This is Mike Schwartz. I'm the founder and CEO of Gluu, and today I'm gonna give you some counterintuitive advice to not use two act- two-factor authentication unless you really need it. Remember this old definition of two-factor authentication is two or more of something you have, something you know, something you are. Back in two th... Read More

Key Insights

• Two-factor authentication is traditionally defined as using two or more categories of evidence: something a person has, knows, or is. It remains valuable because misidentification is described as a root cause of many large hacks, making stronger authentication an important tool for preventing breaches.
• The best authentication experience is no authentication step at all because a system that already knows who the user is creates the least friction. The practical goal is therefore not constant authentication, but a design that requests stronger evidence only when the risk of an action warrants it.
• Trust elevation is the transition from a lower form of identification to a higher form when additional confidence is needed. It reconciles security and usability by allowing ordinary activity to proceed with less friction while reserving multi-factor authentication for transactions carrying greater risk.
• A bank's text message before adding a wire recipient is a simple trust elevation mechanism. The password establishes an initial level of confidence, while the text message adds another check because the bank wants greater assurance before permitting a sensitive change.
• Identity assurance is framed as risk mitigation rather than certainty about who a person truly is. The trust elevation definition discussed in the talk accepts that absolute knowledge is unavailable and focuses instead on reducing the risk that the user is not the expected person.
• Passwords remain dominant because deployability matters alongside security and convenience. Research cited by the speaker indicates that other authentication mechanisms may be more secure or convenient, but no person-identification strategy is described as more deployable than passwords.
• Centralized authentication policy is essential for scale because organizations may operate dozens or hundreds of applications. If each application independently implements trust elevation and multiple authentication methods, the organization must repeatedly reproduce complex business logic instead of managing decisions through a shared policy system.
• OAuth 2 can implement a policy decision point and policy enforcement point architecture for trust elevation. In the described model, a person uses a client to access APIs, the resource server relies on the authorization server, and the authorization server serves as the policy decision point.

Questions & Answers

Q: When should an organization use two-factor authentication?

An organization should use two-factor authentication when the risk of a transaction warrants greater confidence that the person is correctly identified. It does not need to challenge users during every interaction. A lower form of identification can support ordinary activity, while a sensitive action, such as adding a wire recipient, can trigger an additional authentication step as trust elevation.

Q: What is trust elevation in authentication?

Trust elevation is the process of moving from a lower form of identification to a higher form when an action requires more confidence. Its purpose is not to establish absolute certainty about a person's identity. Instead, it mitigates the risk that the person interacting with the system is not the expected person, especially during sensitive transactions.

Q: How does trust elevation reduce authentication friction?

Trust elevation reduces friction by avoiding stronger authentication when the current transaction does not require it. The system can accept an existing, lower level of identification for routine activity and request another factor only when risk increases. This approach combines improved identification with better usability because users are not repeatedly challenged without a transaction-specific reason.

Q: What is an example of trust elevation in online banking?

A bank may allow a customer to log in with a password, then send a text message when that customer attempts to add a wire recipient. The text message provides an additional authentication check because the proposed change is sensitive. This staged process raises the bank's confidence at the moment greater assurance is needed.

Q: Why are passwords still widely used for authentication?

Passwords remain widely used because they are highly deployable. According to the research described in the talk, some authentication mechanisms provide greater security and others provide greater convenience, but no strategy for identifying a person is more deployable than passwords. Their continued dominance therefore reflects implementation practicality, not a claim that they provide the strongest possible protection.

Q: Why should trust elevation policies be centralized?

Trust elevation policies should be centralized because organizations can have dozens or hundreds of applications. If every application implements its own rules for multiple authentication methods, each one must reproduce complex business logic. A centralized policy model lets shared decision-making guide authentication requirements while individual applications or services enforce the resulting decisions at the appropriate points.

Q: How can OAuth 2 support trust elevation?

OAuth 2 can support trust elevation through a policy decision point and policy enforcement point architecture. In the model described, a person uses a client, such as a mobile application or website, to access APIs. The resource server relies on the authorization server, which acts as the policy decision point and helps determine the appropriate access requirements.

Q: What roles do OpenID Connect and UMA have in this approach?

OpenID Connect and UMA are identified as OAuth 2 profiles that evolved to solve different problems related to access and trust elevation. UMA is expanded as the User-Managed Access protocol. The talk proposes examining both profiles, along with collaboration on trust elevation across organizational boundaries, as parts of a standards-based approach to authentication and authorization decisions.

Summary & Key Takeaways

• Stronger authentication can help prevent breaches caused by misidentifying people, but requiring it for every interaction creates avoidable friction. The proposed alternative is trust elevation: begin with a lower form of identification, then require stronger evidence only when the risk of a particular transaction justifies greater confidence in the person's identity.

• A bank illustrates trust elevation when it accepts a password for login but sends a text message before allowing the customer to add a wire recipient. The additional check does not claim perfect knowledge of identity. Instead, it mitigates the risk that the person completing the sensitive action is an impostor.

• Trust elevation must be governed centrally to work across organizations with dozens or hundreds of applications. A policy decision point determines the required confidence, while policy enforcement points apply that decision. OAuth 2 can support this architecture, with an authorization server acting as the decision point and profiles addressing different access problems.