This episode of Coffee with the Council is brought to you by our podcast sponsor, Feroot.
Welcome to our podcast series, Coffee with the Council. I'm Alicia Malone, Director of Communications and Public Relations for the PCI Security Standards Council. If you're like most citizens of the modern world, you've probably struggled to remember your password when signing into your computer, your mobile device, or any of the hundreds of websites and apps where your unique data is being held. This is complicated even further when trying to come up with a unique password for every one of those places and then having to change that password periodically whenever prompted by that device or website. It can become overwhelming and frustrating at times and even the best password manager can fall short.
But what if there was a different way to authenticate that it's really you? What if there was a solution to reduce the world's reliance on passwords? That's exactly what we are going to discuss in today's episode. Today, I am joined by Megan Shamas, Chief Marketing Officer at the FIDO Alliance, along with PCI SSC's own Andrew Jamieson, VP Distinguished Standards Architect. Welcome to both of you!
Megan Shamas: Thank you for having me.
Andrew Jamieson: Happy to be here.
Alicia Malone: So, Megan, I want to start with you because you represent the FIDO Alliance, which is an open industry association with a focused mission to reduce the world's reliance on passwords. Tell me more about the FIDO Alliance and how it achieves this mission.
Megan Shamas: Thank you, Alicia. So, you're right. The FIDO Alliance is an association. We're a member-driven organization. We have more than 250 members and we have a common goal - and it is a very focused and maybe audacious mission when you think about it - to get rid of this dependency on passwords that we have because our use of passwords is really the reason why we see so much successful phishing attacks and account takeovers. Literally every data breach that we've had over the past 10 years, when you see the headlines, is a result of often just the loss of a password.
It's only getting worse now as generative AI has made these kinds of attacks so much easier to perpetuate. And it's audacious because passwords are built into the fabric of the internet. We all have used them. We have used them since the internet really was invented. We're trying to change that fabric with something that's fundamentally stronger and easier, and that's passkeys. So, thank you for your question. We do three things to achieve this mission as an industry body:
The primary thing that we do is we build and publish open specifications for phishing-resistant user authentication. And that's where, you know, that's the backbone of passkeys. We also have specs for secure device onboarding, which is the other piece of authentication, when you have devices coming into your network, for example.
We run certification programs to measure conformance and interoperability against those specifications. And then we run market adoption programs to ensure widespread adoption of our technologies. And part of that is working with organizations like PCI and partnering together to ensure that we're getting the education out there about what we're doing.
Alicia Malone: So, I want to talk a little bit more about these passkeys because not everyone may be familiar with this idea. So, what are passkeys and can you talk about how they work?
Megan Shamas: Yeah, I'd be happy to. So, passkeys are cryptographically secure sign-in credentials. You approve the use of a passkey for sign-in through something really easy to you, like using a biometric on your device or touching a security key. But when you ask how does it work, I think the best way to explain that is by comparing to what we do today with passwords and what we might call traditional multi-factor authentication, which is a password plus something else like a text to code or a push notification, for example.
So, in these scenarios, the user knows something. This is they have to know it, whether it's a password or an OTP code, but the service also needs to know it, in order to validate it, right? And so, what happens is when you go to sign in, you need to share that knowledge, whether it's a password or whatnot, and share it with the service, which then also needs to know it to validate it. So, you can see in between here and storing of this information, how easy it could be to steal and reuse that information to take over an account. This is why we have such rampant account takeover. The burden is on our users to recognize if and when they're being tricked into giving away their sign-in credentials.
Now with passkeys, there's no shared knowledge. There's nothing that the user can actually give away. What the user has is a private key, a cryptographic key. It's unique to the service. And the service has a corresponding public key, which you can do nothing with if you were to get into that server, for example. So, when the user approves that sign in, the device and the service communicate with each other to validate that they each have the right key and then the user is signed in. That's just transparent to the user. You don't send any sign-in information or biometric information over to a service provider that can be stolen and used to take over an account.
So, it's really not something you can give away. But what's really important, too, is that your passkey can only be used to sign into the correct website with the correct URL. So even if a user gets tricked and goes to a spoofed site, which happens all the time through phishing attacks, their device will actually tell them, no, you cannot sign in here. And so, there's no burden on the user to have to identify a phishing attack. And that's really the beauty of passkeys is that it is phishing resistant and super easy to use.
Alicia Malone: Thank you so much for sharing that. Andrew, I know that the Council has quite a bit of guidance and requirements when it comes to passwords, but what about passkeys? Does PCI SSC have a stance on passkey usage?
Andrew Jamieson: We do. So, we have a number of requirements when it comes to access to things. And primarily it comes down to Requirements 8.4.1, 8.4.2, and 8.4.3 in PCI DSS specifically we're talking about here. 8.4.1 is about what we call non-console access into the cardholder data environment for people who have administrative access. 8.4.2 is non-console access for everybody, not admin, but everybody else. And 8.4.3 is access from outside the entity's network into the entity's network. And with those requirements, when it comes to 8.4.2, which is all non-console access - so non-admin access, you're already in your network and you're going from that point in the network into the cardholder data environment - you can use passkeys or what we call phishing-resistant authentication in that context, to get into - to authenticate yourself - to get into that particular area of the network into the CDE.
Now, if you're not using phishing-resistant authentication, we require you to use MFA for that, but in the context of 8.4.2 non-admin access you can use phishing-resistant authentication in the place of MFA.
For the other requirements, 8.4.1 and 8.4.3, we recommend the use of phishing-resistant authentication, for all the reasons that Megan was talking about. It's a fantastic technology. It prevents people from having their secrets stolen in terms of password archives or those things being brute forced and stuffing attacks, all the stuff that goes on, because you don't have a secret stored in the backend system you're authenticating to.
But when it comes to 8.4.1, when it's, we're talking about administrative access, when it comes to 8.4.3, when we're talking about remote access into the network, then in those contexts, we require that although you can use, and we do recommend the use of phishing-resistant authentication, you need to have another factor. And Megan did mention that often you will have another factor in the context of these kinds of systems. You'll be using a password or a biometric or something like that. And so that might work in to use that along with the passkey or the phishing resistant auth to act as multi-factor authentication. However, there are some instances where you would not, and we're actually releasing some FAQs to further provide some information on these systems.
Alicia Malone: Now, there are two types of passkeys, a synced passkey and a device-bound passkey. So Megan, can you explain the difference for our listeners and what we need to know about each one of these?
Megan Shamas: Yes, and I think that's important in the context of what Andrew was just speaking about in terms of MFA and phishing-resistant authentication and, you know, it's a triangle and a square and it's one thing, and the same. And there are cases where, you know, requirements might necessitate multiple factors. And then there are cases where phishing resistance is just needed regardless of factors.
And there still could be factors involved, but the phishing resistance is the key part of that. And I think sometimes, to answer your question, terminology sometimes can be a little bit, can be tricky, right, when it comes to these kinds of things. But it's pretty simple actually. A synced passkey is a passkey that you can access across devices through a secure credential manager, like you mentioned before, there's password managers out there. That’s what historically we would call them, but it could be like the iCloud keychain, Google passwords, One Password, Dash Lane, or all secure credential managers by which you could access your passkey across your devices.
A device-bound passkey is a pretty on-the-nose name because the passkey is bound to a particular device, which could be a hardware security key, for example, or another form, like external form factor piece of hardware. It could actually be an app on a phone as well. But what that means is you have your passkey bound to that device. You can actually use that device to sign into other devices, but the passkey doesn't actually leave that device.
Alicia Malone: Okay, that helps a lot to clarify.
Alicia Malone: So, Megan, what is the process for companies to begin using passkeys for sign in instead of passwords? And how do you roll out passkey adoption?
Megan Shamas: Thank you. That's a really good question. So, the good news - so earlier when I mentioned that passwords are built into the fabric of the internet - the good news is that passkey support is now built into almost everything at this point. We really wanted to replicate the availability and ubiquity of passwords with passkeys. So, today, support for passkeys is built into every operating system and browser. Most IDPs support passkeys. We also have a strong vendor ecosystem with certified products that can help support implementation.
Most organizations have a path forward, technically, to move forward with passkeys. I think what we see for the most part with implementations is that number one - I'm glad I'm on a PCI podcast right now - is that there's planning and ensuring that you're meeting compliance and requirements for your organization that require some pre-planning. So, to Andrew's point, you have passkeys and different types of passkeys. There might be scenarios where you need to support additional types of authentication. You want to ensure that you're meeting all the requirements that you have for your different user types. And then you have a path forward and a roadmap forward for that.
And I think the other piece that needs to be planned, pre-planned, is a very important aspect of supporting passkeys is really just change management, and education, and ensuring that your users, whether they're, you know, consumer end users or from a workforce perspective, your employees have advanced notice of what's changing, what they can expect, have some training on that, and really can expect what's going to happen.
Passkeys are very easy to use, but we do find that the more pre-planning and the more education that is put forward, the less likely it is that there's really any issue when it's time to start actually using passkeys. So, technically, the path is there. The organizations have to think about their business requirements, their organizational requirements, their compliance requirements, and just have a solid plan to move forward.
Alicia Malone: So, now, I have a question for both of you. How close are we to a future where account takeover is no longer a threat? And Megan, let's start with you.
Megan Shamas: Well, thank you. I hope closer. I think we have a ways to go here, but I think we're on the right path. I think one of the things that's really important is that organizations that set requirements like PCI - there's other organizations, of course, that put forward guidance such as NIST - are recognizing the importance of phishing resistance, and educating folks about that, and helping them to understand why phishing-resistant authentication is important, and what security issues phishing-resistant authentication solves. So, I think that is a big part of getting us to a point where folks are getting on board with phishing-resistant authentication. They're starting to leverage it. They understand the benefits. So, I think we're on a really great path and I really applaud these organizations, like PCI, for really stepping forward to show the difference and educate on that.
But, I think what we need to do after that is, and it's going to take some time, but we have to then start removing some of the phishable authentication methods that folks are using. So increase the use of passkeys, start removing passwords and other types of phishable authentication methods from being like the backup for criminals to go after, right? Once we can get rid of that, we're going to be at a place where we're going to be in a lot better of a spot, but we're certainly on a great path forward.
Alicia Malone: Andrew?
Andrew Jamieson: Yeah, so I think it's an interesting and exciting time that we're living in at the moment because we spent so long up until this point relying on and using knowledge-based factors for authentication and not just in the computer era. You know, if we go back further than that, the secret passphrases and, you know, knocks on the door and things like this, they were all used as forms of authentication because that's essentially all we had. If you weren't talking to somebody directly, if you're doing something where you didn't know the person, a knowledge-based factor is pretty much the only thing that you had.
We're heading into a point where we're able to leverage the ability of the computing systems that we are using to be better at these things than we are, better at computation, better at storing more complex information, to use not just knowledge-based factors, but calculation-based factors, if you like, position-based factors based on cryptography, to move away from these knowledge-based systems. And I think that's exciting. I mean, not everybody's going think that's exciting, but I think that's quite exciting.
It's not going to solve everything, though. When we think about authenticating into a system, there's kind of three stages to it. There's the enrollment stage where you initially confirm that you are the right person to have that access. There's the actual validation-of-who-you-are stage, and that's where passkeys come in. But, then, there's the ongoing access stage as well. Once you've authenticated, you're not authenticating every packet that you send to that system, you're generally given some sort of token or given some sort of connection that you use over a session or some extended period of time. So, passkeys and phishing-resistant authentication solves that kind of middle point where we are concerned about the theft of passwords being used, knowledge-based factors, computers just being better at it than we are.
But I think what we need to do as we move into the future, to make sure that we are in a perfect future where account takeover is no longer a threat, we also need to solve the kind of the initial enrollment phase, and we need to look at the ongoing authentication phases as well. But, the good news is we've got technology in the pipeline that's going to help with those systems as well. So, how close are we? We're a lot closer, but, as always, there's still work to be done.
Alicia Malone: Well, thank you both because you both offered a very interesting perspective. Is there anything else that you would like to add, in regard to using passkeys versus passwords?
Megan Shamas: I would just say I would love to have passwords not be a thing in my lifetime. That would be a wonderful thing to see.
Andrew Jamieson: I would reiterate that I think phishing-resistant authentication is a great technology. It is something that can solve a lot of the issues that we have with passwords. And I would strongly suggest when people looking at what technologies they're going to implement for authentication, they have a look at phishing-resistant authentication and what it can bring, but also understanding that it is a little bit different to what people are used to and looking into how they can integrate that correctly and securely into their overall authentication architecture.
Megan Shamas: Thank you. If I could add on to that, that's a really great point that I also would encourage more folks within organizations or guidance-setters or policy-setters to heed what Andrew just said, and really look at and try to understand how this is fundamentally different than what we're used to, and ensure that it's being acknowledged in policies being set or requirements being set. It is fundamentally just different than what we're used to with passwords plus factor, factor, factor, and we have evolved the technology and now folks need to also evolve their requirements and their policies along with that. And that will really help organizations get on the right path to getting rid of phishable authentication.
So again, I want to thank PCI for its recognition of phishing-resistant authentication, as well as NIST and other global organizations, who are really seeing that this is something they need to communicate to the folks that heed their requirements. So thank you and thank you for having me.
Alicia Malone: Well, thank you both so much for joining us on Coffee with the Council today. This has been such an interesting discussion and I know I learned a lot. And special thanks to the FIDO Alliance for being here today and for the work they are doing in this space to help secure data.
This episode of Coffee with the Council is brought to you by our podcast sponsor, Feroot.
Like what you’ve heard? Subscribe to PCI SSC’s “Coffee with the Council” podcast by visiting any of the following platforms: Apple Podcasts, Spotify, Amazon Music, Anchor, Castbox, Google Podcasts, iHeartRadio, Pocket Casts, RadioPublic, Stitcher, Audible, Overcast, or Pandora.
