Megan Shamas

speaker

106 appearances 1 recordings 1 series first heard Apr 2025 last heard Apr 2025

Megan Shamas’s voice in public audio — every appearance, attributed to the second.

Trend

recordings per month · last 12 months

No recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.

Appearances

newest first · ▶ plays the moment

Coffee with the Council By PCI Security Standards Council · Coffee with the Council Podcast: Passwords Versus Passkeys: A Discussion with the FIDO Alliance · 29 Apr 2025 podcast

And part of that is, you know, working with organizations like PCI and partnering together to ensure, you know, that we're getting the education out there about what we're doing.

Yeah, I'd be happy to.

So pass keys 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 texted 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 signing credential.

Now with pass keys, there is 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 needs 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.

Showing 21–40 of 106 · page 2 of 6