Alright, so I had a talk yesterday, you missed it.
So today I'm going to talk not about Passball, the open source password manager, which we
are building with my friend here, Kevin Clayton and Shmouty.
I'm going to talk about Passkeys because I have the chance to participate and be a Fido
Alliance member and sit and participate to the Plenary Conference and CPSIG.
You will see Fido, they love acronyms, so it means Credential Provider Special Interest Group,
so because we are a Credential Provider.
So what is authentication, just so that everybody knows a little bit what we are going to talk about.
Authentication is something you know, or something you have, or something that you are,
like biometric, or something you do.
You can even have like behavior based authentication.
So authentication, these days generally a combination of one or two of these factors.
You know about passwords and password based authentication have a lot of issues,
so you have issues of the user selecting a weak password,
or basically people being able to brute force, or like phishing is a big one,
and you have all sorts of other issues.
Generally you can implement content measure to make sure that basically your authentication is good enough,
but phishing is the one that is really hard to solve because it depends on the user.
So you can solve for example password strength selection by introducing a Credential Manager,
and you can prevent a little bit of the phishing with a Credential Manager,
but you still have some room there.
So who has set up Pasky's as a user in the room?
Well quite a bit of people.
Who has as a developer implemented either Authenticator or like implemented Pasky's authentication on the website?
Yeah, three people.
So we can see here that it's still a new topic.
So what is a Pasky?
You will see that Pasky's mean different things for different people,
so I'm going to try to give you like a 10,000 feet view of Pasky's,
and not like go too deep into the protocols and the options for the protocol or particular implementations,
but just give you like a high level view of the landscape,
something that I would have like when I started working on this because it's like really tentacular
and there's a lot of options and a lot of different views.
So Pasky's the official definition is Pasky's a password replacement.
There are public key, private key pairs that are used for authentication using cryptographic signatures.
So basically you have like a site that gives you something to sign and you sign it and you prove that you're you using an Authenticator.
Pasky's are user credentials that are discoverable,
so it's possible for the browser to know if you have a Pasky for a given website for example.
And because in the browser the JavaScript is served by a website,
it means that the website can also discover whether you have credentials.
So these Pasky's are stored within application or security keys and they may be synced across devices.
So this is the new stuff we've seen in the previous talk that we were talking about device-bound Pasky's,
the Pasky's that are sitting on devices, but they are now a new class of Pasky's that can be synced across devices.
So you can see this is the lay of the land like depending on like who you ask about Pasky's,
they will tell you maybe they are like thinking about device-bound Pasky's,
so Pasky's that are on physical devices or if you ask Google and Apple,
they will talk about sync Pasky's and sync Pasky's are basically keys that can be synced across multiple devices.
So you can for example have them on your laptop and on your phone or you can basically transfer them
or like do an attestation using your phone while you're trying to authenticate on your laptop.
And these Pasky's are supposed to be exportable and transferable,
but in practice they are only transferable within a given ecosystem.
So for example Apple will not let you export Pasky's to Windows for example.
So it's their advertiser's being like you know interoperable,
but because they are not coming from the open source world like we do,
interoperable for them means different things.
So they are also another class of Pasky's which is called up level Pasky's
which generally have lived with the device-bound Pasky's and meaning that they can be used for other things
or you have like additional properties added to them so typically you'll see them in banks.
So for example like a bank application will use Pasky's to sign transactions
or they will use additional signals to unlock a Pasky's something that is not there with a classic authenticator.
For example they will check like you know your location or like your working hours
like you can do all sorts of different signals.
And you can build a custom authenticator so like you can build like the UI that you want.
You don't necessarily have to follow like the OS or like the physical device design.
So there are a lot of different requirements.
We've seen like basically Pasky's means a lot of things.
So like on one side you have like people that are working on the enterprise level.
So people that want hardware keys that are like very strong and you cannot export them.
And on the other side you have Google and Amazon for example they don't really care that it's very,
they want the friction less experience.
So they are ready to trade a little bit of security for usability.
So for example when you're doing a checkout using Amazon they want you to go as fast as possible
through that checkout and pay.
Even if there is a security issue they will be okay to give you back your money.
But if you do that with a bank they are not like having the same mindset.
So on one hand you would have like Pasky's that require certifications.
The banks will check is it the authenticator that I gave you to authenticate.
Is that really your personal device?
And on the other side you basically have like a website like Google that just want to show
like okay you authenticated with the UB key but they don't really care like which one it is.
It's just to present you like okay you have these Pasky's and this is the kind of authenticator that you are using.
And on the enterprise side they will issue for example for like super high security setup
they will issue you like a security token that is just for you.
So you can see that these are some privacy implications.
So for example if everyone was using like a device that is unique for each of us and we log in on each website with this device
you would be able to do cross domain tracking.
So you would be able to see like okay this guy logged there and then he logged there.
And this is a privacy issue obviously.
So on this side you want privacy.
On this side you want basically no privacy because you are in an enterprise setup.
So all of these are like very complex requirements and they are all fitting in the same standard.
So basically like it's a little bit complicated to know like what's going on.
But the common denominator is phishing resistance the fact that the Pasky is domain bound.
So like you have one Pasky for Gmail, one Pasky for AWS.
But you don't reuse the same Pasky twice.
And it's always supporting HTTPS.
They made this choice which is very wise.
It's like no support for HTTP.
So the Fido2 project is a project that works with the Fido Alliance.
Fido Alliance contain like Google, Amazon, Visa, but also like TALES, you know people doing like security devices.
And on the other hand you have like the WebOtent protocol which is managed by the W3C.
So you'll see like basically people working on the Fido Alliance are also part of W3C.
It's the same people, you know for example the person at Google is the same on both projects.
And together this is called the Fido2 project.
So on one side you have W3C that manage the WebOtent protocol.
And on the other side you have Fido Alliance which manage the Ctap which is credential.
Sorry, client to authenticator protocol.
So basically the relying party is the website you're trying to authenticate to.
It uses WebOtent over HTTPS.
Then you have the client which is basically your browser and the JavaScript application that is running in it.
And you have the authenticator.
So authenticator can be the OS platform.
It can be like a device, can be like a UB key, can be anything that is basically Fido approved.
And these days it can even be credential manager.
So it can even be like Bitwarden or Dashlane or OnePassword.
And the interface for client to authenticator is a bit more messy than WebOtent.
Basically you have like it works with Bluetooth, it works with what I call, everybody calls monkey patching.
So basically if you want to integrate in the browser in JavaScript and become an authenticator,
for example as a password manager, you will just hijack the JavaScript API and replace them with what you want.
So that technique is called monkey patching.
It's the only way for a browser extension, for example, to act as an authenticator.
But you have like also proprietary protocols, for example, like when the Google Chrome browser wants to use the Google authenticator,
you know, you don't know what's happening underneath.
They are using their own stuff.
So I hope that's clear and gives you like a high level view of what we're talking about.
So there are two ceremonies.
There is the attestation ceremony, which is the registration.
And there is the assertion ceremony, which is the login.
So there are no other operations.
So for example, you cannot list what are the pass keys available for a given relying party.
You cannot delete pass keys.
These are not part of the protocol and need to be implemented separately.
Like it's not normative.
So we will see that this goes some issues.
So the attestation ceremony, you have the client, which basically post a username.
So this part post a WebOtten attestation option is not normative.
You can do whatever you like.
As long as you send a username, basically the URL doesn't matter.
So it's for the relying party to decide what is the language that it wants to use.
What is the URL?
So recently they introduced WebOtten.wellknown file that you can place on your web server
to basically say like, OK, this is my attestation URL.
Then the relying party reply with the public key credential creation option,
which includes the RP, which basically the ID of the relying party,
the challenge that the user need to sign, and some other options.
Like for example, we've talked in the past, in the previous talk, people were saying,
like, do you check for user presence?
Do people have to enter a pin?
This is basically the moment where the relying party can say like, OK,
I want to use this algorithm and I want to check the user that way.
I will require user presence.
I will require you to do user verification.
And then the client does basically what it wants.
So from that, the client called the navigator credential API.
There is not a WebOtten API.
Basically, we use a JavaScript API, which is the credential API,
which can be used for other things, but it's used mostly for the WebOtten protocol these days.
And then we basically enter a setup protocol or something else.
So either like a proprietary protocol, but here I put setup for, you know,
like clarity because it's the one that is the most defined.
So same, you will send some data about the RP and the user,
and the authenticator will assert the parameters,
see if the crypto operation is supported.
So it's asking to use a particular type of key.
Can I create such keys?
Then collect the user gesture.
So like either enter or enter the pin.
And then generate the credential and generate the signature.
It will return the attestation statement and the authenticator data.
And the client will send this information over to the relying party.
The relying party will assert if the key is valid
and will check the signature.
Is it valid for that particular key?
And it will check if the RP ID is also matching.
So that basically you don't have a client that use another request from another website.
So we keep the property of having a domain bound process.
So the assertion ceremony, I'm not going to detail it again,
but it's pretty much the same thing except you're not like giving the new public key.
You're just signing with a key that is already there on the authenticator.
And then what about account recovery?
So obviously if you lose your device or you lose your passkey,
then what do you do?
So there are two types of account recovery.
There is account recovery for the RP.
So basically the solution to passkey is more passkeys.
So it's good if you have like device bound passkeys
because then you need to buy more devices.
It makes a lot of sense when you're selling devices.
And you can also use passwords.
So generally you have a website like Amazon that will let you have a password
but they will propose you to have passkeys on top.
So basically you will default to passkeys
but you can still use your password for account recovery and magic link.
So basically passkeys are as good as the account recovery mechanism.
So we're kind of back to square one.
Unless you get rid of these methods for account recovery,
you're not like really changing your security posture in my opinion.
And on the authenticator side, it's a little bit more complicated.
So I think Apple recommend you to have several Apple devices.
Makes sense.
And then you can also set recovery contacts.
And you have custom procedures.
So I give you like for example what happens on iCloud if you lose all of your devices.
And it's actually possible to do a recovery for my cloud using all your devices
and it's quite smart.
I'm going to say the problem with we have in open source world is we don't have such a service
that is ubiquitous where people have an account.
So for example if we are Ubuntu and Firefox,
we don't have such infrastructure to exchange such a scroll mechanism.
And that's going to be a challenge I think moving forward.
So how does it look like from an authenticator point of view?
It's a work in progress and there's a lot of change.
So like maybe like by the time I put this slide together, it's already updated.
So this is an example on macOS and Chrome.
And so you will see on Chrome by default Chrome will prompt you to use,
when you click continue it will use the Google Authenticator.
So you have the impression that you're using the OS level authenticator
but you're actually using Google Authenticator.
That is leveraging the API of the OS to provide an experience.
But it's not the Google Authenticator, it's not the Apple Authenticator.
So you can see already it's already kind of sneaky because like if you're using Chrome,
they will prompt you to use the Google Authenticator.
But you have some other options.
For example you can use the phone or a security key.
So basically you see there is more clicks if you want to use something that is not Google.
And then you will scan this or press your security key
and you will have the same result.
So if you can even do like two device ceremony
where basically you scan this QR code and then you will unlock your phone
and the signature will happen and will be exchanging through Bluetooth BLI.
So there is no pairing with the laptop and the phone
and you will be authenticated using that mechanism.
So it's possible for example to use like an authenticator on Android phone
to login on Windows device using this mechanism.
So if you use Firefox, you will start directly using the Apple Authenticator.
And it's the same if you're using Chrome, you'll see like basically if you use that option
that was there on the previous screen, then you switch authenticator.
And for me like I don't expect like people that are not like knowledgeable to understand what's going on.
So and it's the same like depending on like the options that are provided by DRP
you may have like different mileage and different user experience.
So it will be quite confusing I think for the average user.
So it's the same if you want to manage your pass keys, they are like buried.
It's really hard to see like how many pass keys do you have and where they are registered.
Same on iOS, if you want to manage your pass keys you need to go to passwords.
So you need to click on the password to see that it's a pass key.
So pass keys are like okay we've solved the password problem, we can all go home, right?
Like that's it, mission accomplished as George would put it.
But no we still have a lot of issues to solve.
Like we have like the what happened when you lose devices, especially when you don't have like a sync fabric
that is common to different authenticator.
And there is no real work being done on pass key management and review as we have seen.
So for example in the future we've seen with the previous talk with quantum computer coming soon.
We will need to roll out new algorithm, maybe we will need to change algorithm faster than we had in the past.
So we will need to revoke keys.
So in order to revoke keys we will need to design experience where the user understand
okay this key is using an old algorithm that is not supported, you need to create a new pass keys.
So we will need to have a user experience to manage pass keys that is understandable for the average Joe
which is we are very, very far from there.
And it's the same like for developers, I think like for developers to understand all the different options
and what they mean when you're implementing as a RP.
It's quite tentacular and you for example you can't follow the implementation of Google
because Google does not care about user enumeration
because you can already send an email to a Gmail address and it will bounce.
So you already have user enumeration in place so they basically don't implement best practices to prevent user enumeration.
But for you, for your use case maybe it's important.
So like you can't even follow like what the big players are doing, you will need to do your research and find out.
And I think this can lead to some problems down the line and we will need to do a lot more of education
on like what are the security problems around pass keys.
There are some other issues as you've seen like the user experience is quite fragmented
and it will not be the same on different OS and different authenticators.
And there is an entry barrier for authenticators so like one of the few open source projects on the Fido Alliance project
it costs around 50K a year to be in the room when these things are being normed
and so it's basically like a pay to play initiative.
And in my opinion for something that is supposed to replace password but so ubiquitous that's an issue.
So we even have like I think Firefox have a seat at the Fido Alliance but they didn't have the staff last year to be there.
So I think it's an issue.
And there's a lot of proprietary protocol and monkey patching happening and like we need to do much more normalization
and I invite you to get involved to be interested about this because if you don't act on it basically they will make the decisions for you.
That's it.
Do you have five minutes? Yes?
All right. Yes?
The complications that you just mentioned to implement that is also true for somebody let's say a software service that wants to offer pass keys to their users.
Yes.
Do they also have to deal with all this complexity?
Is there maybe a simpler way?
Yes.
So do the RP have to do their homework to understand the issues around pass keys?
Yes.
And they are not like super easy to get.
You know like for example if you let's say you're building like a service like that authenticate people using pass keys but it's like a globalized service for your enterprise and you're doing just one pass key authentication on that domain and then you're switching to another protocol.
Maybe you're using an iFrame and in the case of pass keys you may have issues with UI redressal so you need to basically take care of these issues and these are like you need to read the specs and I think maybe there will be more education and more easy resources
and I think we need like all tools like for developers and like not for them to trip their feet on.
And same like what kind of algorithm you should support like we've seen there is a lot of legacy website like maybe like they start creating keys with a certain algorithm but two, three, four, five years down the line when quantum computing becomes like something that you have to do because the state is telling you you have to do it.
Then you know what happened with these keys you know like.
He said earlier that kind of the relying party can say the use of the present for example.
So how does the relying party know that the client actually should that.
So.
How does the client ensure that the authenticator is doing what the RP is requesting.
I think it depends on the option but most of the options are basically like for example the client can ignore that the user needs to be verified but with the data that will be sent back as part of the assertion you would have.
Okay, what what did the authenticator do?
Did he verify the user or not?
So it will be the RP to verify.
Say to the client I want the user to be verified and when he has the response to say did the user get verified?
Yes or no.
So you say I want this but you need to check if it actually happened when you get the final assertion.
Makes sense?
Yeah but you have a password manager so someone says please make sure that the user is present and you sign the challenge and say oh I didn't say the user is present but you actually like because you can do that.
Yes.
There's no way for the website to know that the password manager is present.
Yeah that's where the Fido certification comes into play.
But it's like nobody wants to be like you know caught off and like say like hey look there you know so it's also like a gentleman agreement that you're gonna respect and do.
But I could I could suspect like that some you know people that are like do it yourself kind of thing they can make their own authenticator that does whatever they like.
But for example a bank may refuse to use an authenticator that is not Fido certified.
So you know depends also on the RP.
Because you assert which service are you using for the station.
When the.
Well often.
So on your response do you know who certified that.
Yes so you have information so it's like in the response do you know do you have information about the author of the cater yes so you have information which is I level which is what they call the a a good which is basically a global you you ID.
That says like you're using like a UB key five but you also have like older version of this way where you have like actual certificate and you have like a signature that you know like.
So this is stored in the MDS of the Fido alliance so if you are like for example a bank and you want to make sure that.
You know it's not somebody pretending to be a UB key.
You can actually see the certificate the route certificate and check against that assertion.
One minute that doesn't make sense so you have you have two level you are one which is like the user agent kind of thing that most are using but you have another one which is like more complex that involves like cryptographic and signatures.
We've seen some examples with the ecosystem and what about the system.
Is there anything like that piece for private.
On the unique system basically like to my knowledge not much is happening I think there is a talk with a GNOME the GNOME team was going to present like what's what's happening on the Linux site but it's way behind in terms of like Microsoft.
Hello Apple.
Kitchen and Google.
I've not seen an open source one like but you have like credentials manager like for example.
Bitwarden or dash lane that are basically can bridge the gap in an ecosystem where there's no OS level support.
Thank you very much.
Thank you.