Overcoming the roadblocks to passwordless authentication

It’s a well-known fact that humans are the weakest link in any security strategy. Verizon’s latest annual data breach report found that over 80% of breaches in the “Basic Web Application Attacks” incident pattern were due to stolen credentials. Not surprisingly, the root causes of most breaches are social engineering, default passwords, or sharing passwords, all of which can defeat even the most sophisticated security solutions.

passwordless roadblocks

Of course, defense-in-depth helps mitigate these weaknesses. And moving away from passwords to passwordless solutions is an effective means of making it harder to steal credentials. A solid and maintainable identity infrastructure also helps because knowing who your users are is half the battle.

Understanding behavioral patterns and reacting to anomalies is also important. These three components are critical to an effective defense-in-depth strategy in a hybrid, multi-cloud world where a typical enterprise will run many identity systems.

There are a variety of roadblocks associated with moving to passwordless authentication. Foremost is that people hate change. End users push back when you ask them to abandon the familiar password-based login page and go through the rigamarole of registering a factor or device required for typical passwordless flows. Further, the app owners will often resist changing them to support passwordless flows.

Overcoming these obstacles can be hard and expensive. It can also be exacerbated by the need to support more than one vendor’s passwordless solution. For example, most passwordless solutions pose app-level integration challenges that require implementing SDKs to support even simple flows. What happens if you want to support more than one solution? Or use your passwordless solution as both a primary identity and authentication provider and a step-up authentication provider? Or you want to layer in behavioral analytics?

There is a way to address these human and technical challenges standing in the way of passwordless adoption using orchestration. Although common in virtualized computing stacks, orchestration is a new concept in identity architectures. An identity orchestration layer makes it possible to modernize older apps without rewriting them so they can work with new identity protocols and support passwordless authentication.

For app owners, identity orchestration provides several tangible benefits including the ability for an app to consume any identity service, be protected with passwordless authentication, and be removed from the compliance exception list – all without making any code changes. Meanwhile, identity and security teams will be pleased because their project costs will be lower and timelines shorter.

Best practices for implementing an identity orchestration framework

First, start with a small test group that runs an isolated function and uses a legacy app unique to that function, e.g., the finance department and its accounting app.

Next, develop a rollout plan, including communications and feedback, so you can improve it before expanding the rollout. Ensure the initial group of users clearly understands what to expect and how they benefit from consuming the new passwordless services. Apply what you learn from your pilot group to make communication even more proactive and clearer. Your security team will thank you.

The most time-consuming part of nearly any identity project is working with app owners to integrate with their apps, so keeping them in the loop about how it makes their lives easier and showing them quick wins will make them more willing to cooperate with you as they juggle other business-driven priorities.

Identity orchestration can make a passwordless authentication rollout more palatable for both end users and app owners by minimizing disruption to the user experience and eliminating changes to apps. In the process, it infuses better security into applications and services. So maybe in next year’s Verizon’s DBIR, the stolen credentials attacks number will be closer to 50% than 80%.




Share this