A Guide to WebAuthn(webauthn.guide)
webauthn.guide
A Guide to WebAuthn
https://webauthn.guide/
118 comments
The most common use case today is 2FA, where WebAuthn is the standard way to do something U2F defined only for 2FA.
In this scenario where it's only a second factor, yes, it relies on you possessing a Security Key, and on the bad guys not possessing it. This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.
WebAuthn (and U2F) were specifically designed to register multiple tokens, the server-side stuff described explains how a site insists "Look I need to register a new token, not these tokens which I already registered" while also being open to whichever token you have on login, "Any of these tokens can log in, I don't mind which". So I have a token in my pocket, but if I got mugged I have a backup token at home that can substitute. Well designed sites let you nickname them during registration so you can go "I lost green hulk token but I still have Yubikey" later.
Yes, if you use the flows where both factors are handled by the FIDO token then you're "back to passwords" but with a very important difference. Very, very important:
Right now your password for news.ycombinator.com is known by the Y Combinator servers. Now, I'm sure they take good care of it, using a modern salted and pessimised hash for the purpose, but this creates many extra opportunities for vulnerabilities and a bad guy only needs to find a crack in one place.
Whereas if I have a PIN for my FIDO token the PIN lives on the FIDO token. Not on every web site I use WebAuthn with, not in a database that some poor new sysadmin accidentally uploads to the Cloud, it's not sent over the wire to some Java backend sevice that might accidentally log it, or whatever. The device can insist upon rate-limiting attempts because it's a piece of hardware, like an iPhone.
In this scenario where it's only a second factor, yes, it relies on you possessing a Security Key, and on the bad guys not possessing it. This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.
WebAuthn (and U2F) were specifically designed to register multiple tokens, the server-side stuff described explains how a site insists "Look I need to register a new token, not these tokens which I already registered" while also being open to whichever token you have on login, "Any of these tokens can log in, I don't mind which". So I have a token in my pocket, but if I got mugged I have a backup token at home that can substitute. Well designed sites let you nickname them during registration so you can go "I lost green hulk token but I still have Yubikey" later.
Yes, if you use the flows where both factors are handled by the FIDO token then you're "back to passwords" but with a very important difference. Very, very important:
Right now your password for news.ycombinator.com is known by the Y Combinator servers. Now, I'm sure they take good care of it, using a modern salted and pessimised hash for the purpose, but this creates many extra opportunities for vulnerabilities and a bad guy only needs to find a crack in one place.
Whereas if I have a PIN for my FIDO token the PIN lives on the FIDO token. Not on every web site I use WebAuthn with, not in a database that some poor new sysadmin accidentally uploads to the Cloud, it's not sent over the wire to some Java backend sevice that might accidentally log it, or whatever. The device can insist upon rate-limiting attempts because it's a piece of hardware, like an iPhone.
Unfortunately for the user experience, those tokens typically can’t be cloned even upon initial setup. The practical result of this is that if you intend to keep a second token as a backup, you need to remember to register the backup token individually for each service you use your primary one for. This is unlikely if you keep the backup at home, and it’s downright impractical if you kept it in e.g. a safe deposit box.
I love FIDO tokens, but I’m not confident in my ability to keep myself from getting locked out of a service I use infrequently, and I’m a fairly technical user.
I love FIDO tokens, but I’m not confident in my ability to keep myself from getting locked out of a service I use infrequently, and I’m a fairly technical user.
> Unfortunately for the user experience, those tokens typically can’t be cloned even upon initial setup. The practical result of this is that if you intend to keep a second token as a backup, you need to remember to register the backup token individually for each service you use your primary one for. This is unlikely if you keep the backup at home, and it’s downright impractical if you kept it in e.g. a safe deposit box.
This right here is what drives me crazy about most 2fa implementations (and now apparently webauthn). I currently store 1 backup token offsite, and carry one with me. The problem is - I have no good way to access the backup device (so I can add it to my account) without having both in my possession, which destroys its abilities as a backup token.
I would love to be able to somehow have 2 fido keys use the same key, but I'm not sure how that's possible without exposing the private key externally, destroying some of the device's security properties.
This right here is what drives me crazy about most 2fa implementations (and now apparently webauthn). I currently store 1 backup token offsite, and carry one with me. The problem is - I have no good way to access the backup device (so I can add it to my account) without having both in my possession, which destroys its abilities as a backup token.
I would love to be able to somehow have 2 fido keys use the same key, but I'm not sure how that's possible without exposing the private key externally, destroying some of the device's security properties.
You could have a single soft-U2F vault that contains all your accounts, and secure that vault with your hardware tokens.
Using something similar to LUKS (http://clemens.endorphin.org/TKS1-draft.pdf), you could allow multiple tokens to decrypt the vault without exposing the master key.
The downside is that there’s no way to revoke access to the vault if a copy leaves your possession.
There are tokens that support this. OnlyKey has a secure backup feature where you can have an encrypted backup file. If you lose your physical key you would just load the backup file onto a new key and all of your accounts are ready.
https://onlykey.io/
https://docs.crp.to/usersguide.html#secure-encrypted-backup-...
Allowing backups is as you mentioned a tradeoff of security vs usability. The greatest risk to your accounts is not always account compromise, it can be losing access to your own accounts. With OnlyKey you can choose to enable this feature or not. Backup requires user physical presence and restore requires the backup file and correct key/passphrase.
https://onlykey.io/
https://docs.crp.to/usersguide.html#secure-encrypted-backup-...
Allowing backups is as you mentioned a tradeoff of security vs usability. The greatest risk to your accounts is not always account compromise, it can be losing access to your own accounts. With OnlyKey you can choose to enable this feature or not. Backup requires user physical presence and restore requires the backup file and correct key/passphrase.
There are other recovery modes that don't require a second token.
One common example is a sheet of recovery codes you receive at the enrolling stage that you are prompted to print and store somewhere safely.
One common example is a sheet of recovery codes you receive at the enrolling stage that you are prompted to print and store somewhere safely.
I've got a system where I mail these one time codes (via snail mail) to a family member as a failsafe. I only use this for 2fa, but that ensures that if I lose my key while say out of the country, I can call my family member and they can read me some codes over the phone.
It's a bit archaic in a way, but works wonderfully as an accessable and relatively secure backup strategy.
It's a bit archaic in a way, but works wonderfully as an accessable and relatively secure backup strategy.
> This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.
Yes, that's a good point. No security is foolproof. But this is an easy way to curb 99%
> "back to passwords" but with a very important difference
Also a great point. It may not totally get rid of passwords, but it does stop leaks.
Yes, that's a good point. No security is foolproof. But this is an easy way to curb 99%
> "back to passwords" but with a very important difference
Also a great point. It may not totally get rid of passwords, but it does stop leaks.
What is a "pessimised hash"?
A Google search only turns up HN posts written by you.
A Google search only turns up HN posts written by you.
In FIDO-speak, "platform" authenticators are your laptop or phone, using their contained secure storage, vs "roaming" authnrs like our SoloKeys. Most people assume that the former will be the main way to use WebAuthn. Consumers using keys are mostly enthusiasts/early adopters/special needs.
Mainly in a corporate setting, a separate hardware key may provide a root of trust (and audit trail if the key is modified to be trackable) , with which you can then unlock your devices in a self-service manner.
You're right that software authnrs are a bad idea.
For services that don't want the security to be pierced by such unsafe fallbacks, initial key attestation can whitelist the acceptable authenticators.
One thing that is too infrequently highlighted is that FIDO2 is decentral authentication between you and the services, unlike "login with big-corp".
Mainly in a corporate setting, a separate hardware key may provide a root of trust (and audit trail if the key is modified to be trackable) , with which you can then unlock your devices in a self-service manner.
You're right that software authnrs are a bad idea.
For services that don't want the security to be pierced by such unsafe fallbacks, initial key attestation can whitelist the acceptable authenticators.
One thing that is too infrequently highlighted is that FIDO2 is decentral authentication between you and the services, unlike "login with big-corp".
Phones are one of the most likely things to break given their usage. So then you'd be locked out of the account. Requiring a smart phone or a phone number to authenticate but a high bar in certain regions of the world as well as against privacy-conscious people.
Here's a anecdote about phone and required 2FA: I was in Laos needing to pay rent when my phone broke. I was locked out of TransferWise to get my paycheck because their 2FA is behind their proprietary app so I couldn't authenticate on my laptop. Luckily I had just enough cash in my bank account. Too bad the bank only had 2 2FA options; 1) behind their proprietary app which doesn't allow rooted devices (despite root for more privacy tools on Android) or 2) SMS in which I was in another country so I didn't have access to my home SIM.
Because I needed a new phone to fix this issue, I went to buy a new one online. I couldn't pay for it because I needed a working phone to confirm a payment with my bank.
All of this could be solved by allowing TOTP (which doesn't require a phone) or FIDO2 (which I have a key).
Here's a anecdote about phone and required 2FA: I was in Laos needing to pay rent when my phone broke. I was locked out of TransferWise to get my paycheck because their 2FA is behind their proprietary app so I couldn't authenticate on my laptop. Luckily I had just enough cash in my bank account. Too bad the bank only had 2 2FA options; 1) behind their proprietary app which doesn't allow rooted devices (despite root for more privacy tools on Android) or 2) SMS in which I was in another country so I didn't have access to my home SIM.
Because I needed a new phone to fix this issue, I went to buy a new one online. I couldn't pay for it because I needed a working phone to confirm a payment with my bank.
All of this could be solved by allowing TOTP (which doesn't require a phone) or FIDO2 (which I have a key).
You can make it more convenient by having a specialized USB or NFC device. The NFC handshake is really simple (tap your phone with it). Arguably more convenient than any kind of secure software-based tokens.
You can use psychical, TPM or biometric authentication, like fingerprint. The specs require one to be able to reset a login if device is lost, like with email and code or SMS.
There's usually a pin or a fingerprint reader on the usb device so that it's not usable except by the owner.
I see a lot of comments of people interested to test it out.
If you have a hardware token with NFC, you can now test it everywhere: Mac, Windows, Linux (), Android (all browser), iOS (Safari iOS 13.3+). This is a big achievement as less than 1y ago the story was sooo much different.
If you do NOT have a hardware token, here are some options:
- Windows with TPM or Hello
- Mac with touchID sensor, you have to use Chrome
- Android phone, Chrome mobile, should work with fingerprint and face recognition
- An Android phone itself can be used as a bluetooth hardware token, with Chrome on your laptop.
Hope this list helps, please add if I forgot anything.
If you have a hardware token with NFC, you can now test it everywhere: Mac, Windows, Linux (), Android (all browser), iOS (Safari iOS 13.3+). This is a big achievement as less than 1y ago the story was sooo much different.
If you do NOT have a hardware token, here are some options:
- Windows with TPM or Hello
- Mac with touchID sensor, you have to use Chrome
- Android phone, Chrome mobile, should work with fingerprint and face recognition
- An Android phone itself can be used as a bluetooth hardware token, with Chrome on your laptop.
Hope this list helps, please add if I forgot anything.
> An Android phone itself can be used as a bluetooth hardware token, with Chrome on your laptop.
If you're referring to the caBLE (cloud-assisted Bluetooth LE) transport: this is still being worked on (https://github.com/w3c/webauthn/pull/909 but the actual discussion in the FIDO Alliance is non-public) and at the time of writing only works on Google properties.
To add: https://github.com/herrjemand/awesome-webauthn also mentions implementations completely in software. Whether those are a good idea depends on your taste, but for playing around you don't need any kind of hardware.
If you're referring to the caBLE (cloud-assisted Bluetooth LE) transport: this is still being worked on (https://github.com/w3c/webauthn/pull/909 but the actual discussion in the FIDO Alliance is non-public) and at the time of writing only works on Google properties.
To add: https://github.com/herrjemand/awesome-webauthn also mentions implementations completely in software. Whether those are a good idea depends on your taste, but for playing around you don't need any kind of hardware.
There’s also SoftU2F, a software U2F implementation for macOS.
https://github.com/github/SoftU2F
https://github.com/github/SoftU2F
Chrome beta on mobile didn't work for me with either fingerprint or any other method, the call to navigator.credentials.create just fails. Firefox half-works.
Firefox mobile works for me on https://webauthn.io
Which half doesn't work?
Which half doesn't work?
For me, authentication, though I see it works on that site. Maybe I made a mistake somewhere.
I logged in no problem with Firefox nightly, macOS, and Yubikey nano c.
Why is the information that needs to be sent to the server so complicated? Specifically you need to send the rawId (raw bytes), clientDataJson (json), attestationObject (cbor) and the result of `getClientExtensionResults()` (js object). And then the attestationObject further includes an `authData` field which is itself a structure which contains another field which is CBOR encoded.
Why not a single CBOR object?
Why not a single CBOR object?
Can you clarify whether you mean only the `attestationObject` should be sent to the server or that everything should be encoded as a single CBOR object and then sent to the server?
I mean why are ther multiple objects that have to be sent instead of a single cbor object. And why is some of it cbor and some of it json?
There are two complementary parts participating in the registration and authentication ceremonies, WebAuthn and CTAP. The response from the authenticator, as per the CTAP protocol standard, is encoded as CBOR. We need the JSON parts from the WebAuthn browser API for the parts in the ceremony that talk to the relying party (particularly for relaying the challenge responses, and allowed authenticator algorithms and behaviors).
Gets worse. Some of it is ASN.1 inside CBOR too. Some of it is custom binary format containing CBOR
The answer is as far as I know:
Backwards compatibility with bad decisions made in U2F
Also; relying on base64url is odd as there are no built in functions in JavaScript to encode and decode it.
The answer is as far as I know:
Backwards compatibility with bad decisions made in U2F
Also; relying on base64url is odd as there are no built in functions in JavaScript to encode and decode it.
> Also; relying on base64url is odd as there are no built in functions in JavaScript to encode and decode it.
I'm probably missing something, but aren't window.atob and window.btoa just that? It's not available in Node though.
I'm probably missing something, but aren't window.atob and window.btoa just that? It's not available in Node though.
btoa is base64 not base64url. And even if it was base64url, it takes a "binary string", so using it on, say, a Uint8Array is non-trivial.
Thank you, I didn't realize the URL safe variant of Base64 had a name and that it was this!
What's the story here regarding software tokens? As I understand it, the WebAuthn standard doesn't preclude non-hardware tokens, but doesn't explicitly define support for it either. In particular, I would like to use my phone and its built-in Titan M chip for WebAuthn authentication over the internet, instead of using a hardware token. Is that possible or on the horizon?
That will already work right now!
Go to https://webauthn.io on your phone and it will ask for your pin or fingerprint and then use the titan chip for the handshake! If it doesn't work. Select "Platform authenticator" in the drop down
Will also work on iOS 13 beta.
If your computer has a TPM 2.0 chip then it will also work on Microsoft Edge in Windows 10 (and maybe also other browsers. If they implement webauthb Microsoft Hello API )
Website is implemented with the excellent https://github.com/duo-labs/webauthn library by the way
Go to https://webauthn.io on your phone and it will ask for your pin or fingerprint and then use the titan chip for the handshake! If it doesn't work. Select "Platform authenticator" in the drop down
Will also work on iOS 13 beta.
If your computer has a TPM 2.0 chip then it will also work on Microsoft Edge in Windows 10 (and maybe also other browsers. If they implement webauthb Microsoft Hello API )
Website is implemented with the excellent https://github.com/duo-labs/webauthn library by the way
iOS 13.3 is what's required (not "13 beta"), and 13.3 was released a few weeks ago.
Thanks for the info. This is not really 2FA anymore though, is it? Now WebAuthn authentication is happening on the same device as the one I'm using to log into the service. Is there a way to use my phone as a completely separate factor for WebAuthn authentication?
Webauthn is not a 2fa API. It's an authentication API. One of its usecases is to enhance password login (2fa) but can also be used as a single factor.
That is up to the implementor.
The implementor can ask the browser for certain security features of the authentication device. E.g. is the authentication device the same device as where the authentication flow is happening; is there a biometric check on the device or a pin on the device (i.e. the second factor is there but device-local) who is the manufacturer of the device (with consent of the user; given this is privacy-sensirive info) etc. And the implementor can then make a decision whether a device is 'strong' enough for single factor auth. All this information is cryptographically attested by the device.
You can ignore all that and only use it as a second factor always though. That's totally up to you and how you use the authentication primitives that webauthn provides.
That is up to the implementor.
The implementor can ask the browser for certain security features of the authentication device. E.g. is the authentication device the same device as where the authentication flow is happening; is there a biometric check on the device or a pin on the device (i.e. the second factor is there but device-local) who is the manufacturer of the device (with consent of the user; given this is privacy-sensirive info) etc. And the implementor can then make a decision whether a device is 'strong' enough for single factor auth. All this information is cryptographically attested by the device.
You can ignore all that and only use it as a second factor always though. That's totally up to you and how you use the authentication primitives that webauthn provides.
Thanks again for the info. Sounds like I have some more reading up to do on WebAuthn.
I read that iOS 13.3 supports using a hardware token with WebAuthN. It doesn’t say you can just use TouchID to login without a separate WebAuth token....
> Currently, the WebAuthn second-factor use case (the FIDO U2F user experience) is the only log in flow that is supported. Security key-based biometrics or PIN (without the use of username and password) are not supported yet.
https://www.yubico.com/2019/12/native-support-for-webauthn-a...
> Currently, the WebAuthn second-factor use case (the FIDO U2F user experience) is the only log in flow that is supported. Security key-based biometrics or PIN (without the use of username and password) are not supported yet.
https://www.yubico.com/2019/12/native-support-for-webauthn-a...
*webauthn.io, I assume
EDIT: Disregard the rest of what I wrote here previously, I didn't realize it was Duo Labs's own website.
EDIT: Disregard the rest of what I wrote here previously, I didn't realize it was Duo Labs's own website.
Website is not by me. I fixed the link. Thanks
But webauthn.io and webauthn.guide are both copyright of Duo Labs and so is the library so I guess they can do whatever they want ;) I assume the two websites and the library are by the same author
Also the library lives on the server side ; not client ; and given the license is not AGPL there is no need to state that they're using it either.
(Edit: original comment was accusing me of copyright infringement for some reason)
But webauthn.io and webauthn.guide are both copyright of Duo Labs and so is the library so I guess they can do whatever they want ;) I assume the two websites and the library are by the same author
Also the library lives on the server side ; not client ; and given the license is not AGPL there is no need to state that they're using it either.
(Edit: original comment was accusing me of copyright infringement for some reason)
> But webauthn.io and webauthn.guide are both copyright of Duo Labs and so is the library so I guess they can do whatever they want ;)
Yeah, I didn't realize that. Tried to edit it in, but too late.
> Also the library lives on the server side ; not client ; and given the license is not AGPL there is no need to state that they're using it either.
And I didn't notice that. I thought it was JavaScript, but it was Go all along. Doubly my bad.
> (Edit: original comment was accusing me of copyright infringement for some reason)
I was (wrongly) assuming webauthn.io was in violation of the license of the library because I thought it was a client-side library.
Yeah, I didn't realize that. Tried to edit it in, but too late.
> Also the library lives on the server side ; not client ; and given the license is not AGPL there is no need to state that they're using it either.
And I didn't notice that. I thought it was JavaScript, but it was Go all along. Doubly my bad.
> (Edit: original comment was accusing me of copyright infringement for some reason)
I was (wrongly) assuming webauthn.io was in violation of the license of the library because I thought it was a client-side library.
So, I went on the demo website (https://webauthn.io/) to try it with a recent desktop Firefox.
I enter a username, press "Register" and Firefox gives me a prompt to "login [with a security key] and authorize", with only a "Cancel" button. And that's all that happens.
Wait, so I can only use this stuff with a hardware token ? Bummer !
I enter a username, press "Register" and Firefox gives me a prompt to "login [with a security key] and authorize", with only a "Cancel" button. And that's all that happens.
Wait, so I can only use this stuff with a hardware token ? Bummer !
Firefox lets you enable software tokens, and disable USB tokens: in about:config, set
security.webauth.webauthn_enable_softtoken=true
security.webauth.webauthn_enable_usbtoken=false
Err... and how is my software token generated? Where is it stored? Can I move it around browsers, e.g. use it with my Mobile Firefox after I generated in on the desktop?
In other words, I can't use it in production (yet), because I'd need to ask users to change browser settings for it to work. That's disappointing :(
You can use it in production for users who have hardware tokens (and it is used in production by many sites for 2FA). But if you mean you can't _exclusively_ use it in production, then yes that is probably true since not all users will have authenticators (yet).
It’s almost like the designers thought - we are so damn close to killing the password, but, nah, why bother.
If you're using windows I think you need to setup a pin or the hello auth method.
Once windows has a quick way to authenticate you it'll offer that when you register
Firefox mobile allows using fingerprint.
I recently implemented this in a library (https://pypi.org/project/django-webauthin/), and Firefox mobile (at least for me) won't log you in if you're using resident keys. Registering the key works, but not authenticating. It's odd.
In the future, what will prevent some random border officer from pointing my phone to my face and unlocking all my social media, google/Apple accounts, mail, bank etc?
What's stopping them from doing that now?
My password, pin, whatever, is in my head
In that case you should probably not use this, or if you do, sign out of your accounts. If you're worried about Face ID, you can actually temporarily disable it easily (without even looking at your device) by holding down the power button and volume up until it vibrates.
I am really excited about WebAuthn finally being the end of usernames/passwords and credential leaks/thefts, so much so that I've implemented a Django library for usernameless authentication with WebAuthn:
https://pypi.org/project/django-webauthin/
It's live on some of my side projects, if you want to try it out:
https://www.pastery.net
https://www.eternum.io
https://www.deadmansswitch.net
https://pypi.org/project/django-webauthin/
It's live on some of my side projects, if you want to try it out:
https://www.pastery.net
https://www.eternum.io
https://www.deadmansswitch.net
> After the PublicKeyCredential has been obtained, it is sent to the server for validation. The WebAuthn specification describes a 19-point procedure to validate the registration data
19 points?! I haven’t dug too deep into the details, but so far everything I’ve seen re: implementing WebAuthn seems so... over complicated? Compared to implementing, say, TOTP based 2FA, which is very straightforward.
19 points?! I haven’t dug too deep into the details, but so far everything I’ve seen re: implementing WebAuthn seems so... over complicated? Compared to implementing, say, TOTP based 2FA, which is very straightforward.
Complicated certainly. But over-complicated would imply that there's a significantly simpler way to do it.
The nice thing about software is that it can be copied, so the complicated part only needs to be done once by somebody suitably skilled in the art.
The nice thing about software is that it can be copied, so the complicated part only needs to be done once by somebody suitably skilled in the art.
So this is like BrowserID/Persona but instead of including the third-party email service to prove identification, the only credentials are on device/in-browser, right?
I assume that if you only connect one computer (authenticator) and lose the device, you're either SOL or the service has some workaround where you pre-register an email address or a separate "Login With" service.
I assume that if you only connect one computer (authenticator) and lose the device, you're either SOL or the service has some workaround where you pre-register an email address or a separate "Login With" service.
No, it's a new standard where the site securely negotiates the login with the browser. What happens after that is the browser's job, all the site cares about is that it sees a correct credential.
Eg your password manager could implement this so all you'd have to do is click "log in" and you'd be in, without usernames or passwords to remember or steal.
Eg your password manager could implement this so all you'd have to do is click "log in" and you'd be in, without usernames or passwords to remember or steal.
So, how do you keep someone else from sitting down at your computer and clicking Log In? Am I right in guessing that fundamentally you're back to passwords, in the sense that when you are away you lock your computer screen and have to enter a password to unlock it (or some other implementation that still relies on passwords, like if your browser requires a master password to use its password manager, etc.)
You use some method of authentication, of course. How do you keep someone who has your unlocked password manager from using it? You just make sure nobody is ever in that situation.
The big win is that, with WebAuthn, you don't need to also hide your authentication from site operators, your OS, key loggers, phishers, etc etc.
The big win is that, with WebAuthn, you don't need to also hide your authentication from site operators, your OS, key loggers, phishers, etc etc.
Thanks. Like you said, this is safer, even if a password remains somewhere in the chain, like a master password for your computer. An advantage is that websites are not storing passwords (hashed or otherwise, because it's hard to do well).
I use a Yubikey, so there's no password for me (just a PIN that wipes the key if it's entered incorrectly a few times). You can also use a fingerprint scanner, face ID, etc.
This is a great, highly accessible guide. The biggest value add is in the description of the protocol, although the W3C standard (https://www.w3.org/TR/webauthn/) was also expertly written and is a great, relatively accessible resource. Duo has done good work in this space.
I've written an implementation of WebAuthn for Python-based webapps: https://github.com/pyauth/pywarp that may be useful to implementers.
I've written an implementation of WebAuthn for Python-based webapps: https://github.com/pyauth/pywarp that may be useful to implementers.
Is it fair to call this client side certificates 2.0?
I really enjoy the server-client diagram [1].
I've always thought myself very able to explain technical things quite well to non-technical people, but always struggled to explain the public/private key exchange in a simple way. This is really neat.
1: https://webauthn.guide/#authentication
I've always thought myself very able to explain technical things quite well to non-technical people, but always struggled to explain the public/private key exchange in a simple way. This is really neat.
1: https://webauthn.guide/#authentication
I didn't read the whole thing, but the first few paragraphs make it sound almost exactly like SQRL (ie. no secrets to keep).
SQRL used to be a nice protocol, now it's a completely unusable monster with more than 100 pages of technical documentation.
If you're interested in something similar that actually works and is very simple, take a look at https://github.com/btcontract/lnurl-rfc/blob/master/spec.md#...
If you're interested in something similar that actually works and is very simple, take a look at https://github.com/btcontract/lnurl-rfc/blob/master/spec.md#...
What If I got multiple devices? Does the server have to store multiple keys per user?
Yes, that's what is recommended and most sites implement (AFAIK Twitter for some reason only permitting one :-/)
And how do you enroll the second device?
It would have to be something like;
1) Login on primary device
2) Generate a one-time code or link
3) Enter one-time code or click link on 2nd device
4) Click an “Enroll” button on the 2nd device which would generate a second enrollment saved in the account.
You would have to do this for each and every service so that seems like a total non-starter.
Alternatively, a way to share the private keys securely between the devices. But I’m not sure if there are site-specific salts as part of the WebAuthN signing process which would require additional state be sync’d between the devices in order to authenticate to a new service on both devices?
It would have to be something like;
1) Login on primary device
2) Generate a one-time code or link
3) Enter one-time code or click link on 2nd device
4) Click an “Enroll” button on the 2nd device which would generate a second enrollment saved in the account.
You would have to do this for each and every service so that seems like a total non-starter.
Alternatively, a way to share the private keys securely between the devices. But I’m not sure if there are site-specific salts as part of the WebAuthN signing process which would require additional state be sync’d between the devices in order to authenticate to a new service on both devices?
There's an ascending signature counter that's intended to prevent cloned devices (replay attacks are prevented seperately with server generated challenge). One way around it is clone (backup key) having very high initial signature counter set, so first use invalidates original (on loss). But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".
> But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".
This seems like a huge blocker for adoption. I currently run into this issue with FIDO for 2fa - I store my backup key offsite, which means enrolling the second device requires me to make a special trip to retrieve the device. My current approach is to retrieve the backup token every few months and add it to all of the new services I have enrolled in, but I don't have a good system for remembering all of these services, so I inevitably forget one (despite only using the key on a few services)...
This seems like a huge blocker for adoption. I currently run into this issue with FIDO for 2fa - I store my backup key offsite, which means enrolling the second device requires me to make a special trip to retrieve the device. My current approach is to retrieve the backup token every few months and add it to all of the new services I have enrolled in, but I don't have a good system for remembering all of these services, so I inevitably forget one (despite only using the key on a few services)...
Write the services down. You don't need to keep the fact that you have FIDO tokens secret unless you're keeping them somewhere otherwise unsafe like under a rock in your garden. So a list titled "Services I've enabled for FIDO" with check columns for the tokens gets it done.
That's my current approach, but I'm not as disciplined about writing them down as I should be.
Ah, I see you're thinking about platform devices where the web browser is running on the device being enrolled.
Yes, you'd have to use some other way to authenticate as yourself on a second or subsequent platform device. If you have a separate FIDO token (like a Yubikey or any of their cheaper Security Key products or dozens of others) that would be the obvious first choice to enroll.
Yes, you'd have to use some other way to authenticate as yourself on a second or subsequent platform device. If you have a separate FIDO token (like a Yubikey or any of their cheaper Security Key products or dozens of others) that would be the obvious first choice to enroll.
How are these private keys being stored? It seems to be implied that there is a different public/private key pair for every website so are they stored in the browser? (or at an OS-level?)
In a hardware token, there's generally a single master secret and private keys are derived on the fly for each website you register/log into. So you can use 1 single hardware token with an unlimited number of sites (note that you prob want to register at least 2 tokens per site, in case you loose one, but this is a different story).
The standard also define the concept of resident keys (RKs), that you can use for passwordless authentication (typically with a PIN on the token, to avoid theft). In this case of course each key consumes a bit of storage, so the number of sites is limited. For example, a Solo key can currently store 50 resident keys. To the best of my knowledge, apart from demo sites, the only "real" site supporting resident keys is microsoft/outlook.com, so this is currently not a real practical limitation.
The standard also define the concept of resident keys (RKs), that you can use for passwordless authentication (typically with a PIN on the token, to avoid theft). In this case of course each key consumes a bit of storage, so the number of sites is limited. For example, a Solo key can currently store 50 resident keys. To the best of my knowledge, apart from demo sites, the only "real" site supporting resident keys is microsoft/outlook.com, so this is currently not a real practical limitation.
Correction, resident keys are used for usernameless authentication (you don't need resident keys for passwordless).
I recently (last week) wrote a Django library for WebAuthn (https://pypi.org/project/django-webauthin/) and use it on a few of my sites (https://www.pastery.net, https://www.eternum.io and https://www.deadmansswitch.net, if you want to try it out).
I recently (last week) wrote a Django library for WebAuthn (https://pypi.org/project/django-webauthin/) and use it on a few of my sites (https://www.pastery.net, https://www.eternum.io and https://www.deadmansswitch.net, if you want to try it out).
They are stored on hardware tokens. There does not seem to be a way to have privately generated software keys, nothing like putty's pageant or .ssh/authorized_keys.
WebAuthn seems to be designed by big businesses to take control of the authentication ecosystem.
WebAuthn seems to be designed by big businesses to take control of the authentication ecosystem.
> They are stored on hardware tokens.
Not necessarily: the WebAuthn spec mentions two other types of authenticators in the introduction section (https://www.w3.org/TR/webauthn-1/#intro): "Broadly, compliant authenticators protect public key credentials, and interact with user agents to implement the Web Authentication API. Implementing compliant authenticators is possible in software executing (a) on a general-purpose computing device, (b) on an on-device Secure Execution Environment, Trusted Platform Module (TPM), or a Secure Element (SE), or (c) off device."
> There does not seem to be a way to have privately generated software keys
A specification is something different than an implementation. On https://github.com/herrjemand/awesome-webauthn you'll find (at the time of writing) two software implementations. https://krypt.co/ can be a third if you want to consider a U2F implementation as well.
Not necessarily: the WebAuthn spec mentions two other types of authenticators in the introduction section (https://www.w3.org/TR/webauthn-1/#intro): "Broadly, compliant authenticators protect public key credentials, and interact with user agents to implement the Web Authentication API. Implementing compliant authenticators is possible in software executing (a) on a general-purpose computing device, (b) on an on-device Secure Execution Environment, Trusted Platform Module (TPM), or a Secure Element (SE), or (c) off device."
> There does not seem to be a way to have privately generated software keys
A specification is something different than an implementation. On https://github.com/herrjemand/awesome-webauthn you'll find (at the time of writing) two software implementations. https://krypt.co/ can be a third if you want to consider a U2F implementation as well.
The section https://github.com/herrjemand/awesome-webauthn#software-auth... talks about using Android phones or Wear OS to webauthn with Bluetooth. The section title is misleading. It's not about software tokens, but about turning one's phone or a smart watch into a hardware token.
The section title is correct: they're authenticators implemented in software, not relying on a TEE/TPM or any other bit of hardware for storing the keys. Apparently these don't run on on your CPU architecture and/or operating system of choice, but that's another issue. The claim of "they are stored on hardware tokens, there does not seem to be a way to have privately generated software keys" is incorrect.
Perhaps https://github.com/bodik/soft-webauthn is closer to what you're looking for.
Perhaps https://github.com/bodik/soft-webauthn is closer to what you're looking for.
There are already open source hardware and software available by the people at SoloKey. Both Nitrokey and SoloKey sell the tokens.
If you are looking for a solution that supports FIDO2 and also functions as a hardware password manager (lots of sites still don't even support security keys) check out OnlyKey - https://onlykey.io/
OnlyKey is also open source here are some of the features: - On device PIN - FIDO2 (15 Resident keys) - TOTP (24 accounts) - Static passwords (24 passwords up to 56 char long) - OpenPGP
OnlyKey is also open source here are some of the features: - On device PIN - FIDO2 (15 Resident keys) - TOTP (24 accounts) - Static passwords (24 passwords up to 56 char long) - OpenPGP
sam_lowry_(1)
> WebAuthn seems to be designed by big businesses to take control of the authentication ecosystem.
Can you expand on that?
Can you expand on that?
There is no way to generate your own software key pair as easily as one can do with ssh-keygen.
The whole spec is designed with hardware tokens in mind, software tokens are not mentioned anywhere, and WebAuthn spec designers wave their hands when asked about software tokens.
The whole spec is designed with hardware tokens in mind, software tokens are not mentioned anywhere, and WebAuthn spec designers wave their hands when asked about software tokens.
You can just implement the client in software and use it if you want, the protocol doesn't care. Firefox already ships with that functionality and you can enable it.
>Firefox already ships with that functionality
>and you can enable it.
I can't find anything like that, can you point us to the docs/examples?
OTOH, I see that someone right now posted a reply to https://github.com/w3c/webauthn/issues/1175#issuecomment-570... trying to downplay the issue of purely software tokens
Funnily, https://github.com/herrjemand/awesome-webauthn#software-auth... is not about software tokens but about webauthning with an Android phone or a Wear OS.
I can't find anything like that, can you point us to the docs/examples?
OTOH, I see that someone right now posted a reply to https://github.com/w3c/webauthn/issues/1175#issuecomment-570... trying to downplay the issue of purely software tokens
Funnily, https://github.com/herrjemand/awesome-webauthn#software-auth... is not about software tokens but about webauthning with an Android phone or a Wear OS.
The point is that ssh keys lying around on your laptop aren't the greatest idea either. Where is the root of trust? The password you type to terminal if you encrypt them?
FIDO2 starts with the idea of safe defaults, where either client devices (Android, laptop TPM,...) store the keys safely, or dongle vendors (like us, SoloKeys). These have a business interest in doing their job properly.
But there's nothing preventing software implementations, it's an open standard in that respect (I do have other issues with it but your specific concern is unfounded imho).
FIDO2 starts with the idea of safe defaults, where either client devices (Android, laptop TPM,...) store the keys safely, or dongle vendors (like us, SoloKeys). These have a business interest in doing their job properly.
But there's nothing preventing software implementations, it's an open standard in that respect (I do have other issues with it but your specific concern is unfounded imho).
Here:
https://news.ycombinator.com/item?id=21963399
Which comment is trying to downplay the issue? What is the issue?
https://news.ycombinator.com/item?id=21963399
Which comment is trying to downplay the issue? What is the issue?
@nickray, with ssh, I manage the root of thrust. With Webauthn, someone else manages it for me, be it Yubico or Intel or Apple.
This is a fundamental difference.
This is a fundamental difference.
As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc.
I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qualified for.
This is what I meant by "safe defaults". Yes some people use e.g. password managers, but no, most people don't. Yes, some people manage to use GPG to manage their ssh keys, but no most people, even qualified, don't/can't/won't.
"Bad defaults with patches hopefully making it safe" is just not the way we should be heading.
I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qualified for.
This is what I meant by "safe defaults". Yes some people use e.g. password managers, but no, most people don't. Yes, some people manage to use GPG to manage their ssh keys, but no most people, even qualified, don't/can't/won't.
"Bad defaults with patches hopefully making it safe" is just not the way we should be heading.
I agree with all of your points, I'd just like to point out that, even if everyone ends up using software authenticators (password manager-style) with WebAuthn, we'll still be in a much better position than we are today, where people just use the same insecure password everywhere.
>every end user and mid-level admin handles
>security decisions they're frankly not
>qualified for.
It's better for the society to let them make their share of mistakes. In the longer term, everyone will be safer and, incidentially, more intelligent.
It's better for the society to let them make their share of mistakes. In the longer term, everyone will be safer and, incidentially, more intelligent.
You're wrong. You can manage your own keys. You don't need any big corporation for WebAuthn.
Well, that's assuming that the anti-feature of device attestation doesn't end up being used in the inevitable way that the spec allows:
"But attestation is not spoofable. Therefore, if sites launch webauthn support and accept attestations from the current set of token vendors, future vendors may be locked out of the market: Their devices won’t work because their attestations aren’t trusted, and they won’t be able to get sites to update because they won’t have enough market presence to matter."
https://www.imperialviolet.org/2018/03/27/webauthn.html
"But attestation is not spoofable. Therefore, if sites launch webauthn support and accept attestations from the current set of token vendors, future vendors may be locked out of the market: Their devices won’t work because their attestations aren’t trusted, and they won’t be able to get sites to update because they won’t have enough market presence to matter."
https://www.imperialviolet.org/2018/03/27/webauthn.html
I think the whole attestation thing is generally a terrible idea. It's not impossible to extract data from secure hardware, right now there is not a lot of incentive to do it because it's not going to get you much, spend a month of hardware research to get one user's key, no thanks. But with whole batches of devices having the same private attestation key stored on the device this incentives essentially ransom of security key vendors. I.e. Lets say I am a hacker that spends a month of hardware research finding a vulnerability and extracting the attestation private from a token. Its worth my time because I know this vendor has 100,000+ keys out there that uses this same attestation key. I then request that vendor send me $500,000 in bitcoin or I release the private publicly. The vendor pays the ransom because it's cheaper than recalling 100,000+ security keys. Another issue here is it's not if but when this happens, so when it does how do all of the web sites out there update to block the hacked keys? Lots of web sites never will. Time to rethink the attestation key being stored each token, that's a bad idea.
Yes, if a service says "we only support Yubikeys for login", you should boycott them.
I hope that principle does establish itself among users of the web, but I suspect that if a bank says "You have to use one of these supported devices to access your account online" people are not going to change their bank because of it.
Similarly, if China mandates a government-approved (backdoored?) device when accessing Chinese websites, I don't suppose Chinese citizens are going to boycott those. Other countries might reasonably retaliate by forbidding sites to accept authentication by devices made in China.
Do you think that if Apple decreed that you can only securely log in to Apple websites with an iPhone (or some other device made by Apple) people would switch to Android? It's hard enough to get people to boycott Facebook despite repeated scandals that are much worse than having a whitelist of supported authentication devices.
Similarly, if China mandates a government-approved (backdoored?) device when accessing Chinese websites, I don't suppose Chinese citizens are going to boycott those. Other countries might reasonably retaliate by forbidding sites to accept authentication by devices made in China.
Do you think that if Apple decreed that you can only securely log in to Apple websites with an iPhone (or some other device made by Apple) people would switch to Android? It's hard enough to get people to boycott Facebook despite repeated scandals that are much worse than having a whitelist of supported authentication devices.
If those organizations wanted to do what you say, and WebAuthn didn't support attestation, I doubt they'd say "well I guess we just can't do that" and give up, though.
The only service I have seen that only allows Yubikeys so far is Vanguard.
[deleted]
If you have a Touch Bar MBP this works with Chrome and the Fingerprint Sensor out of the box. On iOS 13 you need a hardware token currently. MacOS Safari doesn't have support.
This is about the same library:
https://www.agwa.name/blog/post/always_review_your_dependenc...
Claims there are it's written by people who don't understand Go that well.
https://www.agwa.name/blog/post/always_review_your_dependenc...
Claims there are it's written by people who don't understand Go that well.
My spider-senses are tingling: Is this tracking I can't get rid of?
I mean, if you are logged in, the service already knows who you are.
I guess your public key could get associated with your identity. But the pub key is only sent when you register, I believe. So I can't see how this would be used for tracking.
I guess your public key could get associated with your identity. But the pub key is only sent when you register, I believe. So I can't see how this would be used for tracking.
Why is everybody acting as if this is some kind of solution to password-based auth? Can you even imagine a world in which a big chunk of the population carry these tokens around and never ever lose them?
As far as I can imagine, it boils down to relying on the possession of a certain piece of hardware instead of knowing a certain password. That is, I have to carry around some kind of USB device and plug it into every computer I want to use. The device holds all my secret keys and does all the magic behind the scenes. But if I lose my device, then I can't log in. And if someone steals my device, then they can log in.
Maybe you can make it more convenient by using my phone instead of a specialized USB device, since everybody is always carrying around their phone everywhere they go anyway, right? But I just want to know that I understand the entire landscape first, from the point of view of the user, at a broad level. What are the user's options? What exactly does the user do? Is this only for smart users? If I made a web app for the general public, and my only method of authentication was WebAuthn, would the average user easily figure out what to do, or would they give up and walk away?
Some have mentioned "software-based" tokens, but then how are those kept safe? With a master password? Then we're back to passwords.