Hi, Josh. Good to see you again. Hope you're not too hot. Now I have some burning questions here. Gonna start off with the trick question, which is, you know what I'm gonna say. Most current biometric solutions allow users to fall back on a password or pin. So doesn't that kind of invalidate everything you've just said.
So thankfully it doesn't, I mean, obviously, as I said, sort of towards the end of the pre the presentation, if the entire interaction could be cryptographic in nature, I'd be thrilled. But when asked to think about threat models, right? And, and, you know, from all the way back to Martin's presentation through mind in a password world, the password travels or the hash of the password travels, right? So the, the target website needs to know something about it. And anybody who's in the middle can potentially, you know, take advantage of some vulnerability to abuse that the threat model for passwordless is actually really different. That pin that you set up on your phone doesn't travel. It only works on your phone and it's sole jobs to unlock a cryptographic key. That's used to communicate with the service you're logging into. And so we go from a world in which all sorts of remote attacks are possibly, there is a man in the middle or on a vulnerability on the server side, into a world where in order to take advantage of your pin, they actually have to either hack directly hack your phone, or they need to steal your phone physically, which is even harder.
And so even there, we get huge gains in security by really changing that threat model. So no, it doesn't have validate it completely. What I love for it to be cryptographic. Yes, but much better than, than the previous world.
Okay. I mean, Martin talked about privilege access management a little bit, and you mentioned it as well. So it's very conceivable that a user these days is, will have different levels of privilege for different systems, even different, you know, clouds, et cetera. So how can, how can passwordless system deal with that kind of situation, which is, you know, likely to happen?
Sure. In the early days what's likely to happen is that it is very similar to what would happen now in, in most push based multifactor solutions where you may have different identities, right? And so in each case, there's a one time enrollment where a specific key pair is generated for that identity. And when one of the cool things about it is that when a service wants your privileged identity, it's gonna send you a request using the public key for your privileged identity. So your mobile indicator's gonna know which identity it's actually interested in. And of course you unlock it with your biometric. And if you go to use your, your non-privileged identity, the request will come in with that public key as well. And so the user doesn't really have to think about that. It just happens in the background, but you may have to enroll, you know, your privileged identity and your non-privileged identity, even though you're using the same index finger as your, as your biometric authenticator, as we move towards a world of, of truly, you know, know digital identity, both of those things can simply be tied to your true underlying digital identity.
And the enrollment could perhaps be done far more seamlessly so that even if there are two key pairs generated the user, doesn't really have to think about it or see it. But in any case, even if there is that slightly longer, second enrollment, once it's done the users still won't have to think about it. They'll just present their finger and that'll be it.
Okay. One, one thing that struck me actually, during your presentation and, and also Martins was for some, for some organizations, the idea of passwordless this a little bit scary perhaps, and they can't quite get their head around the concept. And they like the idea of passwords, particularly in power, where you've gotten, you know, stored in a vault or whatever, and they're rotated, et cetera. So how, how do you deal with that kind of hesitancy or, or skepticism, you know, from customers?
Yeah. And I mean, look, it, it's, it's one of those things where I, if you're an organization that has an IBM system, three 90 in the basement somewhere, you're never gonna convince that thing, that it doesn't need to ask for a password. Right. And so there is an intermediate gentle baby step, one could take, which is rapid in something, right? So one of the things that we've done for long time before passwordless, but in the, in the realm of, of zero trust is we use a reverse proxy, right? Because that, instead of having a simple, single point of entry level of policy evaluation, lets us have granular policies for each application. One can imagine a world in which you wrap that system three 90 in this reverse proxy. So that by the time anyone reaches it, you know who they are, you know, what device they're using, you know, about the posture of their device.
All they had to do to get connected was just present their fingerprint for passwordless. But then the system still asks for its password, right. You know, if that's what you want and it doesn't bother you from a user experience, point of view, you can have your cake and needed to in that sense. But I would say that, you know, cryptographic relationships based on large keys is just indisputably, more secure than, than a password. And, and the management of it is, is, is simpler as well. Especially again, when you move towards that world of digital identity where you've got this way to re-enroll without needing to fall back on a password, it's just more secure. And so take the baby step. Absolutely. Nobody's gonna tell you that there's the one right way to do it, but the more you investigate the technology, the, the more comfortable, hopefully you might feel about it.
And, and I guess that IBM thing you mentioned was some kind of computer, was it that you, that, that used to exist? Oh, that's, that's a
Little, basically enough. It actually, especially in financial services still exists quite, quite a bit, although more and more of them are running Linux rather than the original Z OS operating system, but they're still out there, believe it or not. Okay.
All right. I'm just trying to pretend I'm younger than I really am. So if, if I still needed a password for enrollment, say again, how is that truly passwordless cuz you suddenly, you still got a password there that someone's gotta remember or they write down cetera. So doesn't that kind of,
So again, it comes down to threat model. If, if you're using the password all the time and it's stored on all of your target application servers, the, the risk of a breach is constant, right? Any, any time that somebody finds a vulnerability in that application, you're in trouble, anybody, anytime anybody catches you in the middle of a log on with that password, you're potentially in trouble for an enrollment that requires a password. I have to have you breached at the moment of enrollment already in order for there to be that risk from then on, anytime you communicate to some target application, it's gonna be using that key pair, right? So while the risk isn't zero admittedly, and anything that humans invent the risk is never gonna be zero because the human will probably figure out a way to break it, but the risk is much, much lower. And so when you combine the lower risk with the much improved user experience compared to having to type the password, we sort of feel that everybody wins. But certainly I would never claim that any solution is the, the, the panacea for all potential risks.
So you, you talk about decentralized identity and, and, and a lot of people are talking about that, particularly in relation to the it architectures that we are, we are now getting used to and, you know, the, the endpoint thousands of endpoints and people logging into different clouds and all sorts of things going on. So what maybe first, just quickly define decentralized identity and then maybe walk us through to how you're seeing this playing out in the future.
Yeah. So, you know, it's, it's, it's something that from a, from a definitional point of view, people have different ideas about it. For example, the UK government has what they would call digital identity, which is really what I would call identity proofing. So you provide a copy of your plastic document and they go verify it through somebody, and then they issue you, you know, a certificate in a manner of speaking, you could say that that's a digital identity, but in reality, it's not really you, that controls it. You don't have any auditability over where that's being used. It's a step in the right direction, but, but truly decentralized identity comes when you are the, the controller of that identity. It's very similar. And it relies in fact, rather heavily on blockchain technology as a, as a foundational idea. So if we think about when you create, if, if you were to go to buy Bitcoin, right, you would download an app, that app would create a wallet.
And that wallet is just a cryptographic private public key pair, right? And it has absolutely no value whatsoever until you do a transaction on the network and associate some Bitcoin to your wallet in a decentralized identity world, very similarly, you would create that identity. And that identity would be worthless really because it would be unvalidated until some trustworthy source said, you know, I validated Josh somehow and, you know, signed it and issued you a, a, a digital license for, you know, or a digital ID for, for something. What gets cool now though, is the way that the blockchain works is I can now establish relationships with other entities on that network. And I can engage in transactions like saying I'd like to enroll in Duo's passwordless solution and duo can say, okay, where did this identity come from? What's the transaction history. Oh, okay. The government to the UK validated that identity.
Okay, great. Josh has now unlocked that and signed that with a biometric. I can issue you a password list credential. I don't need to see your password, right. There is no password. It doesn't exist anymore, right? Not only that, but I get to see what data, you know, before any data goes across, I get to approve what duo gets to see about me. Is it my name? Is it my address? Is it my, you know, my computer's inform whatever it is. And then there's a history, a ledger that I can check at any time to look for anomalous behavior, to look for, you know, potential bad actors I've interacted with any sort of thing like that. And it just, it, it really opens up a whole new world of how we can deal with identity. The other thing I like about it is that, you know, when you think about the world as it is today, right?
A lot of the things that are, you know, like credit cards, for example, if you wanted an extra copy of your credit card in a non-digital world, you can't just go make one, you need to have a card printer. You need to have a magnetic, Stripe and coder. And, you know, in a lot of cases, it wouldn't even be legal, but the bad guys do it all the time, piece of cake, right. They duplicate them all the time. They steal your number, they put it on a card and they go use it so hard for the good guy, easy for the bad guy with digital identity. It's the other way around, right? You in possession of your biometric and possession of your private key could decide. I want to add my identity to my tablet. In addition to my phone piece of cake, somebody in the other side of the world, though, who doesn't have your biometric and doesn't have your private key really, really hard, right? And so it solves that problem as well, which is one that I'm not sure people think about every day as being a problem. They're just used to it being hard to get their credit card replaced. But in fact, we could make it really easy.
Sure. I, I, you mentioned the UK government. I know that they, it was, was trying to provide a single identity that you could access all government services. And I dunno how far that, but that was sort of on the right line. So you could access your tax, your health and everything else that the government sort of looks after. So it's, it's, it's true is happening in the real world. You zero trust is a something. We also talk about an awful lot where, where does passwordless fit into the zero trust philosophy?
Sure. So, I mean, one of the key pillars of, of, of zero trust is from the user point of view, right? Cuz there's, there's zero trust. As it applies to devices and software talking to each other, the zero trust, as it applies to humans, interacting with stuff, there's really three pillars from the human interactivity point of view, verify the identity of the user, right? And traditionally we did that with passwordless plus MFA, verify the identity and posture of the device. And of course have granular control over that at the application level. And this really is a huge advance. It sort of merges steps one and step two, right? We want to securely verify the user in a way more secure than a password, right. We wanna use a biometric and we also want to tie that to the device, right? So we wanna make sure that we're dealing with a trustworthy up to date, well postured device that also happens to hold the cryptographic key material.
That's tied to our identity so that we know that user and device pairing is assured, right? And so it really helps us merge those two columns together. And it does it in a way thankfully, and very importantly, that isn't any harder for the user. In fact, it's easier for the user because as we've seen, right, if you make it harder for the user, it really doesn't matter how much more secure it is. There's that adage out there. I think it goes something like there's nothing more dangerous than a, an employee with a deadline and a credit card, right. Hook all around any security measure you put in if their life is being impacted too much by it. So the it's a win-win to get the improved usability and improved security.
Okay. So how, how would you recommend organizations? They wanna start passwordless where, where do they start? What's a good few step. First steps.
Yeah. I mean, from our point of view, we've definitely committed to the decision that we think federated applications are the, are the best way to start one because their approach to, to getting rid of passwords and establishing, you know, trust relationships based on certificates and keys, it's already there, right? The foundation's already laid the, the ability to be identity agnostic is also really good. It doesn't really matter what cloud service you're using. It doesn't really matter which identity provider you're using. As long as they're supporting one of those open standards, you know, it's gonna work. And of course we are going to support all of those standards as well. And so it's literally plug-in play, I didn't do a demo of the administrative side of it during the, the presentation, but enabling password, listen, duo on one of your federated applications is a tick box. It literally takes less than 10 seconds and you're done. And that is not something that, that really can be offered. In any other context, it would have to be a much longer process.
Is it easier for perhaps a cloud native smaller startup type of organization to switch to password list and those organizations that have a lot of legacy architecture still?
Absolutely. But that's something we really aim to address. One way that we did that is that from the get go, our reverse proxy, which has actually been around for a few years, had built in SAML support. And so in fact, if you were approaching an application that you're hosting on premise and you protect it with the reverse proxy, you will be able to do passwordless at least to the point of the proxy. And if the on-premise application does SAML as so many VPNs and on-prem things like JIRA and confluence and all those things do today, then actually you'll be single signed on all the way, way through even to the on premise app. So we looking to address that, obviously also addressing the, the windows log on side of things and the Mac log on side of things that you can do that passwordless as well opens up other options for signing into, to on-prem and thick client applications as well. That will come a little bit later for us, but it's definitely something we, we intend to do.
Okay. So finally then when's this gonna be available?
Yeah. So at the moment, you know, we're, we're looking to get into, into some, some private and public previews in, in Q2, fiscal Q2. So that'll be later on this year, actually with a GA probably probably early next year, but of course, you know, as, as anybody in product would tell you dates can move a little bit. But the nice thing is that I, I actually in, in our, in our lab, I've been playing around with it for quite some time now. So the product does exist. It's really fun and easy to use. We're just not quite ready to share it with everybody else yet, but that date is fast approaching.
Okay. Well, great, good luck with that. That concludes my interrogation. So I'll hand us hand back to Christopher in, in Germany.
