As we enter the password-less era (or so I hope!), I would lie that I see wide adoption and enthusiasm. But the truth is we still don’t quite understand biometrics, well at least in the part of how the biometric data is managed from a technology standpoint. Businesses are slow in adoption using variety of excuses, mainly around management of the method. There are those brave who break the barriers though. Ebay now offers WebAuthN instead of the password (as an option) and if you want to trade using Freetrade, you’ll be surprised to see that the concept of password faded to black.
While I am on a quest to break the barriers and debunk the myths about password-less, it’s perhaps a story for another day. Today I want to focus on a concept that helps with the password-less management, specifically by loosely coupling our authentication device to the channel we need to authenticate. Truth to be told, it can be applied to password flows, too, but I am allergic to password, so please forgive me for not including it here.
If you don’t like to carry portable FIDO2 devices, here’s what you can do instead.
Cascaded Context
Sounds big, doesn’t it? In reality it’s a form of an omni-channel authentication or authorisation. You start the journey on one device – for example a laptop, but you don’t use that channel to authenticate, in fact, you don’t even need to store anything on the device to keep it persistent. You off-load that process completely to another device, which cascades the trust down. How does it help password-less? Well, if you remove the concept of ‘something you know’ altogether, you’re faced with a chicken and egg scenario. How do you enrol a device (a laptop’s browser, a phone or a tablet) into let’s say a WebAuthN flow? What Ebay does is… reverting back to a password. So not quite password-less. I have explained the biggest problem of a password here. The process of enrolment becomes the most vulnerable.
For example, you open a website on a shared desktop, identity yourself (username) and hand over the authentication to your mobile phone or laptop. You log in (passwordlessly, goes without saying) on the device you own and the information is cascaded to the device that requested authentication in the first place.
Why not just Cascaded Device Trust?
Device is important, but context is a wider term. You may have the same device having good or bad context. While this is a semantics discussion, I prefer to use the word context, as it implies the modern AI-powered risk based authentication solutions.
Apple Passkeys
First commercial implementation of Cascaded Context Trust. The idea was to remove any dependency on the device we are accessing and move it to our mobile phone. Sceptics will say, we are only moving the problem elsewhere (as you now depend on your mobile phone), but let’s think about it. Nothing in security or life is a 100% thing (apparently only death and taxes are certain). While not everyone has a smart phone, the vast majority of us do. Let’s solve the problem for the majority first and then look into the minorities and solve their problems in another way.
While many have reservations (after all the crypto material now travels between devices), it’s still much safe than the passwords, because the most important element here (private key) is never stored server side. We can no longer say it never leaves your device, but that the price we need to pay for usability.
What does the experience look like? You enter your username in the browser and it displays a QR code. You open your phone’s camera, scan the QR code and the phone is asking you for consent to log in. You verify it with your TouchID or FaceID and the browser logs you in. It requires proximity between the devices (which implies bluetooth enabled on both and being within the range of each other).
You can then register this new device with WebAuthN without the need of a OTP, which is prone to a replay attack. Chicken and egg scenario solved. Well almost…
QR Code Login
Although the journey starts the same as in the passkeys scenario, it works a bit different, because we actually don’t share any crypto information between devices. You scan a QR code with your phone, which in turn opens a browser (let’s say Safari), which is already enrolled for WebAuthN passwordless authentication. A unique, random (ok nothing is random, pseudo random) transaction identifier is associated with your account within a time limit. That transaction ID is then passed in the request URL, you complete your WebAuthN journey and the backend sends the message to the original channel (which generated the QR code) that the journey was completed. The beauty of this method is that you don’t need any app on the phone (apart from the default web browser) and it is vendor agnostic (will work on any phone that supports web browsing and WebAuthN). You can find a great write up and example implementation of this method by Stéphane Orluc here.
Workforce, MDM and Risk Bound Devices
If we wanted to be more restrictive on how the trusts cascades, we could introduce additional controls. For example, you can log into a new device (cascade trust) only from a device that meets specific criteria. For example, it’s managed by MDM or at the time of validating the risk assessment of the context was low. You cannot however cascade further until you achieve higher assurance level with the device you cascaded the trust to.
Trust vs Authority Based Recovery
I wrote about the concept here, but it goes hand in hand with the Cascaded Context Trust. Imagine you lost your only device that was enrolled with passwordless authentication. We are back to the chicken and egg scenario. What we can do is use peer based identity proofing to recover access to your account. Your peer (helper, who needs to be enrolled as such beforehand, with your consent) can generate a magic link sent to your email. You then open the link and register the new device and to top things off, it’s strongly authenticated by your helper. We are doing a context switcheroo throughout the journey to achieve this. If you lost access to your email (I got you covered), you can use two independent helpers who don’t know about each other to construct a two-piece item (not a password) that would allow you to do the same thing.
Conclusion
It’s time. Concept of passwords is old and weak as much as passwords are cheap. New identity is omni channel and multi device. And before you start challenging the idea of using your phone as the main trust device, imagine how long it would take you to notice you lost it. For most of us, digital addicts very little time. Let’s embrace it. Put it this way – would you prefer to mess about once when you register the new device (regardless of the reason) in a simple manner and then have frictionless experience for an significant amount of time or… type that password over and over and over and over again, knowing, there’s nothing you can do to protect it, if it leaks.