Account Recovery, without Password Resets

One of the joys of passwordless authentication is the huge reduction in help desk tickets arising from users who have forgotten or otherwise can’t access their passwords.

Organizations that have embraced Okta FastPass report lower costs of support after the initial hurdle of getting their users enrolled. They also report greater confidence in their security posture, knowing that access to sensitive resources requires a tight coupling of a user and their device.

Those organizations that continue to rely on passwords as a primary authenticator still have good options for securing sign-on events: they can lock down sign-ins using device trust and multifactor authentication, among other options. 

In any case, strong sign-in policies shift the threat actor’s available options to the next weakest point in the user lifecycle: enrollment and account recovery. Threat actors continue to enjoy success when impersonating users in calls to IT helpdesks, requesting the service desk staff perform a password reset (typically followed by follow-up calls to reset other MFA factors).

These attacks are often successful in organizations with outsourced service desks. Outsourced IT service desk professionals are highly incentivized around how responsive they are to client needs. In doing so they are highly vulnerable to a skilled social engineer who impersonates a senior figure in a client organization. While it’s the subject of some debate, it’s the client organization’s duty to set up outsourced service desk professionals with the guardrails they need to withstand social engineering attacks. Those guardrails need to include strong identity verification processes, which present challenges in a remote and extended workforce.  To help solve this problem, Okta has partnered with multiple identity verification providers and specialists in recovery workflows to prove the identity of an inbound caller. 

Once a user’s identity is verified, the next question is how to provide support desk personnel with a safe way to recover access for the user. That’s where Temporary Access Codes (TACs) come in very handy. 

Constraining account recovery

Even if you have sufficiently verified the identity of an inbound caller, there are residual risks associated with service desk professionals being asked to create and share temporary passwords. A temporary password can be shared or intercepted and abused prior to use and rotation by the legitimate account holder.

Ideally, any use of temporary credentials is constrained to an expected context. A TAC, unlike a temporary password, is a time-bound secret that is classed in Okta as an authenticator, which means it can be subject to authentication policies. Administrators can decide, for example, which users are able to be issued a TAC, how long the TAC is valid for use, and from what location and device a TAC can be used. 

TACs bring an important account recovery option to passwordless environments, where a misplaced security key or other possession factor may temporarily prevent a user from accessing their resources. 

But the utility of a TAC doesn’t end there. Any Okta workforce customer now has the option  to disable the issuing of temporary passwords or resetting of passwords and MFA factors from front-line helpdesk roles. 

I’ve previously recommended the use of custom admin roles to create helpdesk roles that constrain the ability of service desk professionals to reset the factors of privileged users like administrators. Now there’s an opportunity to go one step further and create custom admin roles that can’t reset passwords or factors.

The custom helpdesk role would need, at minimum:

• The ability to read user information (“View Users and their Details”)

• The ability to add a user to a specific group of users that are eligible for assigning Temporary Access Codes (“Edit user’s group membership,” “View groups and their details,” “Manage group membership”)

• The ability to issue Temporary Access Codes (“Manage user's Temporary Access Code”)

More crucially, the custom helpdesk role would no longer need to be assigned permissions to:

• Reset a user’s password (“Reset users' passwords”)

• Assign a temporary password to a user (“Set users' temporary password”)

• Reset the MFA factors of a user (“Reset users' authenticators”)

• Enroll a user in MFA (“Enroll users' authenticators”)

Once an inbound caller has verified their identity, a TAC issued to a user for account recovery could be constrained to be:

• Only valid for a few minutes

• Only used in conjunction with another previously enrolled factor (“authenticator method chaining”)

• Only used from a specific set of locations

• Only used from a registered or managed device

For guidance on how to use TACs as an account recovery factor, please refer to the following help desk article.