4 ms·

Apple is considering this to be multi-factor authentication all in one click, the something you have (the phone) and the something you are (FaceID or TouchID).

by zaroth 6y ago

Apple is considering this to be multi-factor authentication all in one click, the something you have (the phone) and the something you are (FaceID or TouchID). For the site perspective, if you ask for attestation then you will have cryptographic evidence of this. No more SMS 2FA! Apple is promising to do something extra with their attestation process which they call "Apple Anonymous Attestation" to mitigate the issue where attestation allows tracking the same device across different websites even if they are using different usernames. Not included in the current release, but "coming soon". The process of enrolling an authenticator is presented as a "one and done" event, but of course the devil is in the details. Shared accounts would need multiple authenticators, and what happens when you upgrade your phone or lose your phone? I guess this gets handled like a password reset. You probably will want users to be able to add/remove authenticators, which means also having to name them. The enrollment process in this video highlights the upgrade path from a password login to a FaceID/TouchID login, but doesn't give us the UI flow of a new login. It seems like sites would need to implement a standard registration page and then perhaps swap out the password field with a Next button which would prompt for the FaceID/TouchID enrollment. Makes me wonder how does this compete with or tie into the 'Signin with Apple' if a site wants to offer one-click registration? Will my Mac and iOS devices automatically and securely sync the private keys between their respective Secure Enclaves so that I can signin from any of my devices after enrolling on just one? Lastly, how about the case when returning to a site where the user is on their enrolled device, but there isn't a cookie present. It looks like the site can detect that the device supports Webauthn, but I'm not sure if it can automatically detect that the device already has an account enrolled with the site? The call to 'credentials.get' includes the 'credentialIdBuffer' which is a value provided by the platform authenticator and saved during registration. But in the video they make it sound like 'credentialIdBuffer' is actually optional? It's not even clear to me in the official WebAuthn spec [1] if this value is required, or if the authenticator will just use the RP domain to present the user a list of available credentials? Ultimately I'm wondering if a user without a cookie will still have to type in their username before the site can prompt them for FaceID/TouchID authentication. [1] - https://w3c.github.io/webauthn/#dom-publickeycredentialrequestoptions-allowcredentials https://w3c.github.io/webauthn/#dom-publickeycredentialreque...

alanwaketan 6y ago
The allow list is optional. If you don't provide one, Safari will show all accounts on the device registered with the RP, or fallback to ask security keys if there is none.
tialaramex 6y ago
The value is not required, that's why it says "OPTIONAL" in capital letters at the link you gave. WebAuthn has two scenarios. For something like an iPhone or a Windows laptop we can choose to have the device store a heap of credentials mapped to domain names. So your Safari sees this is cat-videos.example and the iPhone knows credentials for cat-videos.example so .get() fetches those credentials without needing IDs and the site doesn't (if it does things this way) need to ask for a username first. This is called "resident key" because the device remembers which keys it has and you can have your site say during registration that you prefer this outcome, or even that you insist upon it by setting it as "required". The other scenario is older and very clever, it is used for things like a cheap FIDO USB dongle. It stores nothing, the device doesn't know who you are. This means it cannot provide that seamless "no need to enter your username" UX, however it does work well as a second factor and can be used as a sole factor if you want. How can it work if the device doesn't remember credentials? Well the WebAuthn ID is deliberately big enough to "hide" encrypted keys inside it. Instead of remembering your credentials after registration like this Safari feature, a cheap FIDO dongle encrypts the private key it'll need and then gives that to the web site to store as an ID, alongside the public key. When you give the site your username, it fishes out the IDs associated with your user and hands those to get() in that buffer you spotted. The user's web browser shows these IDs to any FIDO dongles and if one of them made that ID it can decrypt it successfully and authenticate you. So the overall answer to your question is: It depends. The cheapest simplest WebAuthn setup uses it only as a second factor and would need a username every time. A very nice UX focused on being as seamless as possible for Apple users wouldn't need a username unless you're using a device you haven't authorised this way before. The video shows such a UX because that's what Apple wants you to do for their users.

by zaroth 6y ago

alanwaketan 6y ago

The allow list is optional. If you don't provide one, Safari will show all accounts on the device registered with the RP, or fallback to ask security keys if there is none.

tialaramex 6y ago

The value is not required, that's why it says "OPTIONAL" in capital letters at the link you gave. WebAuthn has two scenarios. For something like an iPhone or a Windows laptop we can choose to have the device store a heap of credentials mapped to domain names. So your Safari sees this is cat-videos.example and the iPhone knows credentials for cat-videos.example so .get() fetches those credentials without needing IDs and the site doesn't (if it does things this way) need to ask for a username first. This is called "resident key" because the device remembers which keys it has and you can have your site say during registration that you prefer this outcome, or even that you insist upon it by setting it as "required". The other scenario is older and very clever, it is used for things like a cheap FIDO USB dongle. It stores nothing, the device doesn't know who you are. This means it cannot provide that seamless "no need to enter your username" UX, however it does work well as a second factor and can be used as a sole factor if you want. How can it work if the device doesn't remember credentials? Well the WebAuthn ID is deliberately big enough to "hide" encrypted keys inside it. Instead of remembering your credentials after registration like this Safari feature, a cheap FIDO dongle encrypts the private key it'll need and then gives that to the web site to store as an ID, alongside the public key. When you give the site your username, it fishes out the IDs associated with your user and hands those to get() in that buffer you spotted. The user's web browser shows these IDs to any FIDO dongles and if one of them made that ID it can decrypt it successfully and authenticate you. So the overall answer to your question is: It depends. The cheapest simplest WebAuthn setup uses it only as a second factor and would need a username every time. A very nice UX focused on being as seamless as possible for Apple users wouldn't need a username unless you're using a device you haven't authorised this way before. The video shows such a UX because that's what Apple wants you to do for their users.