Root Causes 204: PKI's Role in Passwordless

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

February 2, 2022

In previous episodes we have defined passwordless identity authentication. In this episode our hosts explain PKI's specific role in passwordless authentication, along the way clarifying the difference between password-masking and true passwordless technologies.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe did a recent episode where we defined passwordless. It was a concept, a very important concept in the world of access and identity. Today, we wanted to talk very specifically about how PKI fits into passwordless.

Jason SorokoThank you very much, Tim. I think there is a lot going on here so we might not even cover all of it. The term passwordless means so many things to so many people. And that’s not a bad thing. To me, the trend is positive. I don’t think anybody would argue otherwise. Passwords themselves, let’s hope that X number of years from now they’re really only being used for legacy systems where we can’t get rid of them and hopefully we could still put MFA technologies on top of them or isolate them with some good network.

Tim CallanMinimize the risk.

Jason SorokoExactly. So, legacy systems, which we are gonna talk about down the road, is something that I think is another topic area, but I want to highlight PKI in terms of passwordless because it’s just such a core important concept within that space. Let’s talk about passwordless that is not PKI-related just to help to draw the comparison.

And there are vendors out there who are doing very good work at essentially creating very large, automated password managers, for a lack of better way of saying it. And that’s my term for it. It might not be theirs. But to me, really what they are doing is they are masking underlying password or other forms of authentication technologies that are perhaps obsolete, whatever, but they are adding some layer of non-password authentication on top of it. So, essentially, it’s an abstraction layer. That’s what I would describe it as as the highest-level concept and on the bottom of the underlying the abstraction layer is the legacy authentication technology and then above the abstraction layer is something that you could consider passwordless.

Tim CallanBut let’s be clear, Jay. In this scenario, there’s still a password being used. It’s just not being used by a human.

Jason SorokoCorrect. So, when those vendors go out and claim that they are passwordless, what they actually really mean to say is the user interaction, the day-to-day user interaction with the underlying system, they are not entering a password.

Tim CallanThe user experience is password free and there is benefits to that in all fairness. Remembering your password is horrible, people reuse passwords, people use guessable passwords. There’s all kinds of things that you can get rid of if you get some kind of password management or Single Sign-On system in place but we should not confuse that with eliminating passwords. They are not the same thing.

Jason SorokoCorrect, Tim. And so, therefore, it begs the question, is this really passwordless? Well, I think the argument can be made that what it is is an important bridge technology. And I think there is a place for it. It’s just you can imagine that marketing departments are under pressure to use buzz terms and passwordless is a buzz term so they are gonna use it. Is it completely accurate? I don’t know. Does it matter? Well, it does matter but that’s why we are talking about it here so that you can challenge your vendors. If you think you are buying a passwordless technology, if you think you are getting away from passwords in your environment, you really have to challenge your vendor and say, hey, is this a security technology or is this a user experience technology?

They’ll probably say both and they might even be right. But the fact of the matter is the underlying password isn’t going away. It kind of reminds me of the old trope that I keep going back to, which is Microsoft’s Pass-the-Hash attack, which has been around for 20 years plus because of the fact that backwards technologies and legacy technologies for authentication you just can’t get rid of them. And so, therefore, unless you can go to a more application centric world where you can apply modern forms of authentication at the application level, if you are still doing network level authentication or authentication to Active Directory – whatever you legacy is – then you probably are going to need bridge technologies in order to be able to deal with that through time. And, I know that Microsoft is doing a good job to even change that and we can into that, but the fact of the matter is there are non-Microsoft technologies that are legacy that we are probably never gonna extinguish from our enterprises for many years to come. Therefore, definitely these bridge technologies are gonna be important. So, that’s the non-PKI, non-passwordless passwordless technologies. I had to address it because then everything else from here kind of starts to make more sense in terms of what I would call true passwordless. Really and truly getting rid of the passwords.

Tim CallanSo, true passwordless and, by the way, if you are interested in more background on this, it’s our Episode 177 – What is Passwordless? It’s worth going back and listening to but just the crisp definition is true passwordless means there isn’t a symmetrical shared secret anywhere in the process. Correct, Jay?

Jason SorokoI think that’s a clean definition, Tim. So, the title of the podcast was PKI in relation to passwordless and so, to me, what’s the deal here? Let’s talk about the non-managed, the ones that aren’t typically certificate-based passwordless. This is actually quite common, Tim. Quite common. In that, you are typically going to have a crypto key on a mobile device. Let’s just use that as an example where the mobile device is being used as an out of band form of authentication for whatever it is you are logging into. Whatever you are logging into typically involves whatever that vendor has created an integration for. That could be something like Windows, Mac, Linux, on the desktop. It could also be cloud applications that are popular. Typically, this kind of vendor would have had to have built an integration into these different kinds of systems. Once you have the OSs and once you have a good chunk of the cloud, well, you have a good customer base.

Typically what happens is that vendor will quite often white label their technology to somebody who is building a major cloud application and that cloud application can say to their users, hey, download our app and when you authenticate there will probably be keys generated either on the device or we will pass keys to you, crypto keys, and then as part of your authentication sequence, when you basically announce, hey, I am me – however it is that you are doing that. It could be a biometric. It could be a lot of different things that you are using for your authentication, but no password. Then ultimately, the challenge for what used to be the password would essentially be the usage of your private key signing some sort of challenge document. Which essentially completes the authentication sequence.

Tim CallanSo, in this case, the authentication of the human is replaced with something that’s local to the device? So, a biometric pin, something like that and then the actual over network authentication is done with PKI even though in this scenario, it’s not certificate-based.

Jason SorokoThat’s it. It’s not certificate-based but it is crypto key-based.

Tim CallanSure. And it certainly can be cryptographically sound and all the rest?

Jason SorokoExactly. Tim, you’ve probably seen these USB form factors that contain crypto keys. YubiKeys are quite common. This is essentially using a mobile device to carry those crypto keys around rather than say your YubiKey. Therefore, how easy is it to roll out these kinds of authentication schemes for your employees? Well, it kind of depends. These things need to be rather custom built. A lot of integrations needs to be made and a lot of work has been done to build these things. And I congratulate anybody who has done it especially if they have done it a way that completely avoids username and password. However, remember what I said, Tim, when I said as part of the authentication sequence announcing yourself. Those are words I choose very carefully because sometimes the announcing yourself, some security architects choose to use a username and password as that announcement. Therefore, if you are using a username and password to essentially begin the authentication sequence and then you finish the authentication sequence with a crypto key challenge, is that passwordless? Because I’ll tell you right now there are vendors in the world who are doing that exact thing right now and calling it passwordless.

Tim CallanWell, according to our definition that we said earlier on this episode that would not be passwordless. What I’m trying to deal with though is is it equivalently secure? Because you do have that crypto key check in place if you will. So, maybe the answer is not passwordless but no foul?

Jason SorokoNo foul perhaps in terms of security but perhaps a foul in terms of the user experience as we talked about earlier.

Tim CallanI was focused on the security aspect of it but the years of experience point is a valid point.

Jason SorokoSo, isn’t this interesting, Tim. We went from a world where things were mostly black and white, maybe a couple shades of gray and now we have so many shades of gray that we almost need a matrix to figure out all these different, is it passwordless? Is it not? Is it secure? Is it just a user experience issue? I think if you are procuring this kind of technology, these are the questions you need to ask and that’s why we are doing this podcast. I don’t think we are telling you what’s the ideal world for you because you have to deal with your blend of legacy technologies that you have to face. The question though is what are the balances that you need to strike with the compromises that you need to make.

Tim CallanNow the other thing that occurs to me, of course, in this scenario is, as we’ve pointed out, it is keys; it isn’t certificates and there are unambiguous benefits to certificates over, what do I want to say, pair keys, raw keys and that’s why we use them. That forces the keys to have some kind of termination date. It gives you control. You can disable a key pair anytime you choose and if you build your certs that way, it gives you the opportunity to envelope other information that you might care about – metadata around those keys. Like who it’s assigned to. In this scenario that you’ve just described, we don’t have any of that and that strikes me as a weakness. What’s your take on that?

Jason SorokoI definitely think that because of the fact that these things are so custom built, you have to keep in mind that policy management for crypto keys needs to be done through some kind of policy manager then. Because of the fact that the crypto keys they just exist. They don’t have any inherent policies wrapped around them the way that a certificate does. Therefore, that’s why, Tim, you see so much noise in this zero trust market around policy engines. Because of the fact that crypto keys are used in so many different places and they don’t manage themselves.

Tim CallanNope. They’ll sit there forever doing what they do - regardless.

Jason SorokoExactly. Therefore, how secure is your policy manager? What is the process of provisioning the keys to where they are? What’s the process of a policy management in this case of employee leaves the company is clear enough. But those crypto keys are still sitting around. All of the sudden, you have to ask a lot of questions.

Tim CallanThere’s no record or knowledge of where they are. If I have a private key and I have access to that private key and I copy it onto a device that I put in my pocket, there’s no way to ever know that.

Jason SorokoAnd, Tim, remember, a lot of these kinds of applications as well. What you are gonna find is in a decentralized world – and that’s gonna be future podcasts that we’ll talk about that – but in a decentralized world, a lot of what’s gonna happen is a lot of these applications that perhaps generate their own keys, mobile applications as an example, the reason why they are gonna be able to generate their own keys is because you really - - the whole point of the use cases in a decentralized environment is you want to do business with somebody that you don’t know anything about but you still want them to be able to interact with you at some basic level and so keys are gonna be generated that nobody really manages or owns. It’s almost like the application is dealing with them somehow and a policy engine is doing all of the smarts behind the scenes. There’s a lot of architectures being built around that right now. Some of them completely valid and good and some of them – well, sometimes it’s just a bunch of developers in Silicon Valley who were like, well, here’s some keys let’s do something with it. I’m hopeful in that people will do things properly but, again, I think this is where as an enterprise if you are procuring these technologies, you gotta ask the questions.

Tim CallanFair enough. Then, of course, there is the pure certificate, pure passwordless scenario that we have talked about in the past in 177 but we must not neglect that.

Jason SorokoLet’s talk about certificate-based passwordless. The ideal use cases obviously being centralized enterprise environments and by centralized, I mean centralized so that, yes, you still can work with third parties, but you are the one who controls the certificate issuance. That could even work for very diverse infrastructures such as consortia that might have multiple players. I mean this is the real beauty of what PKI gives you in terms of trust models. Yes, in most cases it’s gonna be some form of a centralization, but I think that covers the majority of non-blockchain based use cases that exist in the world which is the majority of them. Therefore, what are you gaining by having that cert? It’s not just the policies. We could go on and on about the ability to inflict policy on the certificate, renewal cycles, all those things that you and I, Tim, in certificate lifecycle management talk about all the time. But you also get things such as the ability to have trust models that span across third parties. You also have the ability to perhaps not rely on a policy engine quite as much as you did have to in other scenarios, especially for renewal cycles.

Tim CallanWell, if nothing else – really for two reasons – if nothing else, number one, you always have the fallback that you can just kill any cert at any time. So, you do have that oh shoot scenario. Where you go kill the cert and then the other part of it is that they’re all time limited. They are all gonna age out now. If it’s the private CA, if you want to make them 100-year certs then you haven’t really solved the problem but if you have a reasonably short certificate lifecycle then you’ve put cap on the amount of damage it can really do.

Jason SorokoThanks, Tim. So, let’s go back to that crazy shades of gray matrix we were talking about earlier. Is certificate-based authentication that’s strictly certificate-based passwordless? Well, yes, it is.

Tim CallanThat seems clear that that is.

Jason SorokoTherefore, if you have a certificate in your TPM and your Windows laptop and you are using that to authenticate into your Windows desktop, well, that’s passwordless. You might have something like a biometric that’s associated with it so that the announcing of yourself is perhaps just showing your face. And that’s fine. That works. There’s many ways to do it and we are not people who do certificate-based authentication aren’t stopping you from choosing whether you want to use a pin code, a biometric, etc. To me, they’re all just ideas to protect that pin, be able to also announce yourself as part of the authentication process.

Let’s then talk about security. Well, I don’t think anybody is gonna argue that a certificate with policies wrapped as the envelope around that certificate that’s stored in a secure element is less secure than any other authentication technology that exists today. That’s like maximum secure.

Then let’s move onto the other thing that should never be an afterthought which is the user experience. Well, if you can just look at your laptop screen and then you are authenticated with the strongest authentication possible, can you have an easier authentication. To me, it really is the best of all worlds of, well, it is passwordless, it is the most secure and it is the easiest to use when its implemented properly.

Tim CallanFrom a UX experience, let’s also not neglect something that you and I have talked about ad nauseum in this podcast, but I guess we’ll do it one more time which is that the user experience behind passwords is horrific. Like we are not even comparing that against, uh, oh hey, this is seamless and the other thing requires a little bit of - - no. This is seamless and the other thing is just plain awful. So, the UX gap I think is quite great.

Jason SorokoAnd when you are talking about visibility to your users, the ability to write the policies, the ability to have administrators that can push certificates through provisioning technologies that are modern, the ability to do that across third parties such as contractors or across consortia for interoperability, try that with a crypto key. Try that with a username and password. Good luck.

Tim CallanI think that covers the spectrum of our shades of gray.

Jason SorokoI think it does, Tim. I wanted to keep this pretty tight and to let you guys know, there’s so much noise in the vendor community. Some of it is even warranted. My only statement here is – and I’m repeating myself is – challenge your vendors. Ask a lot of these kinds of questions and you might be surprised at the answer you get.

Tim CallanI want to put a punctuation mark on this with one more question and I believe I know the answer too, but I’ll ask. Is there, apart from PKI, is there another technology that offers true passwordless authentication as a possibility?

Jason SorokoLet’s say in the military, Tim, there may be military applications for extreme level biometrics. In other words, the military has not issued you say a crypto key or a certificate or any other form of secret. In other words, it’s not a shared secret. It’s not an asymmetric secret. You are not possessing a secret that has been provisioned. You merely have been provisioned by whatever biometric of their choice is. I would say that if it’s the standard thumbprint, eye print, voice, this is not what I’m talking about. I’m talking about something where you are putting your hand on a device that costs a million dollars plus and it looks at your vascular system and it says nobody else statistically could be this. To me, that’s probably the closest you get. I don’t know how many of you want to have a million-dollar system for every point of authentication.

Tim CallanSo, yes but that scenario is irrelevant to the average human or small enteprise.

Jason SorokoYou do it at scale, certificates are to where it’s at.

Tim CallanGreat. That’s what I thought you were gonna say and I just thought it deserved to be asked.

Thank you very much, Jay. I think that is a great overview of where PKI fits into passwordless. I do believe this is a topic we are going to continue to touch in the future as we explore this but probably a good place to stop for today. So, thank you. This has been Root Causes.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!