I was trying really hard to focus on the technical aspect of identity, but today, you need to let me talk just a little bit. I have to tune in to a small amount of philosophy to make a point. Let’s rock!
Authority Based Procedures
In a nutshell, you need to speak to an administrator who can make changes on your account or provide a path to recovery. Call centers and helpdesks are the best examples of what I class as authority in identity.
Password Recovery
Almost every enterprise asks for self-service password recovery capability from the identity vendors. Yet a great part of the industry still spends money on recovering access for their users via call centers. The numbers vary, but the latest I heard at Identiverse in Denver earlier this year, was that a password reset might cost as much as $70. Multiply it by a number of users, it will add up to a hefty bill.
The most famous self-service recovery method is via email, we are very familiar with it, but… what happens if we’re recovering a password for the email itself? Well, you may say, you need another email account (in fact Gmail does that), but I feel like we’re chasing our tails. From a security perspective, if I wanted to be grumpy I’d question if can we trust that the user is the only person who can access their email. In most cases we accept this risk, but there’s a better, stronger way.
Possession Factor Recovery (e.g. lost MFA device)
Not all, but the overwhelming majority resorts to call centers and even identity proofing. FaceTime with the support team, show my ID, show my face, show I’m real, maybe answer some questions. The assurance is based on authority, rather than trust, because let’s be honest… In a large enterprise of thousands, the person proofing my identity knows absolutely nothing about me, about the validity of my document or any of my biological characteristics, like the voice, tone, accent, face expressions etc. We know that proofing can be done automatically, but most either cannot afford it or don’t want to spend the money on yet another solution. I suspect the cost is the main driver here.
Trust Based Recovery
I went around and asked a good few of my friends and colleagues, both identity professionals and people from completely different walks of life:
Who is the best person to confirm that you are… you?
The answers weren’t surprising and they were very consistent. Mum, dad, sister, brother, wife, husband, friend. People close to you, who spend significant amount of time with you. Our jobs are our second homes and people we work with become our ‘extended’ families. Some of us spend more time with our colleagues working, than with the family members at home. That gives us a great opportunity to move from authority – call center, to trust – peers. But is it as secure as call center? I think we can make it even more secure with much lower cost and friction.
Don Peppers and Martha Rogers, Ph.D., in their book Extreme Trust: Honesty as a Competitive Advantage, talk about building blocks on trust, which TTEC took further and broke down to:
As I looked into the trust relationship further, I arrived at somewhat Euclidean conclusion.
Our customer service center sits within the relationship number 1. If I lost the trust relationship with the enterprise (password of MFA device) we are trying to rebuild it using the same channel. It brings us back to the position where we were during the very first moments of the relationship, during sign-up.
But if the enterprise trusts the manager (or any other peer) – relationship number 3, and the manager has a trust relationship with the employee – relationship number 2, then friends of my friends are… my friends. Why not capitalise on it?
Let’s place the building blocks of trust on this diagram. We have empathy, as we all know how it is to lose access. We have transparency, as it’s a very structured and documented process. All we have to do is add accountability, which is also easily achievable through logs and notifications. I’ll even add non-repudiation to the picture through mutual authentication, but you can read about it in the next section.
What we have left is excellent customer experience, with on-demand recovery. It’s much easier to get through to your boss or peer that to a busy call center. They will usually call back when you’re in a meeting and if you don’t respond… process goes stale. Empowerment is there, as the recovery is in the hands of the employees. All we have left to place is recognition. The mere fact we’re discussing this issue is a recognition of users’ needs and time.
Peer Authorised Recovery Flow
The initiation
First of all, the procedure will be triggered (technically) by the helper – the manager or the peer. User has to ask for it through available channels (e.g. in person or via video call). Recovery relationships need to be strictly configured (org structure or peering). We need that to prevent fraudulent attempts. The helper logs into the authorisation server and starts a recovery procedure, which generates a magic link. That magic link is then sent to the helper who chooses the channel to pass it to the user who needs the access recovered. After all the chap in trouble may have lost his mobile or cannot log into the email.
Theoretically speaking that magic link can be passed using unsecured channel, because this process is ‘peer authorised’, requires further authentication, so in isolation cannot be used for any malicious intent. The magic link works only once, so the moment you load it, it is invalidated.
It takes two to tango…
The non-repudiation comes from a mutual authentication of the parties. If the employee lost the password, they will need to authenticate using the possession factor (SMS, authenticator app etc). If the secondary factor device is lost, the good old credentials are needed. It’s a complementary process.
The magic link we talked about earlier takes you back to the journey the manager (helper) started. Only now we are switching the identity context to the person who required help. User is asked for credentials and after they are validated the manager approves the flow with a push notification to her/his mobile phone. The user can then register a new MFA device.
If we need to recover from a lost password, the user first needs to approve the request in the authenticator app before being prompted for a new password. Pretty neat, right?
The flow
Theory is great, but how, without spending a lot of time and dev resources?
Those processes are usually built around IGA solutions and workflows and take as much as 6 months to deliver. They require a lot of development outside of the authorisation server. How then?
The answer is orchestration. Every modern identity platform should have one. The era of chained events is gone, enter intelligent, adaptive journeys, which should be integral to the authorisation server. I have built this journey in just a couple of hours using ForgeRock’s Identity Platform. It’s a crude PoC, but it works. There’s a little bit of JavaScript, but this is well within low-code realm.
In the platform UI, it looks something like this.
What if I lost both…
The concept of non-repudiation and mutual authentication goes away if the user lost both the password and the MFA device. We may not want to trust the helper to a degree where they can (intentionally or unintentionally) take over user’s account. One way to solve this problem is to add another helper (two-man rule). We could design a logic and a flow that requires both helpers to work in isolation in order to provide assurance and proofing of the user. Helper 1 can generate the magic link, while helper 2 would authenticate the flow. Ideally helpers would not be aware of each other.
Summary
Well, that’s it folks, but far from being the end of the story. This concept can go beyond classic username/password + authenticator app or even workforce use case. You can take the trust triangle and deliver account recovery for passwordless scenarios, email accounts and who knows, maybe one day even bank accounts. Stay tuned, as I will be building passwordless recovery flows next! And when I say passwordless, I mean no OTP’s that need to be entered into the login screen!