I recently used auth0 to implement passwordless login (via "magic link" emails) for a client project. Auth0's documentation is not great, but some of their blog posts are pretty good. In any case, if you're interested in WebAuthN, you could do worse than reading what Auth0 has to say about it:
I don't want to let the password go. It gives me the freedom to rightfully access my service if I just know the secret, without any entanglent to some app, device, or other account.
Is there a solution for the fact that all of your accounts will be secured by the same "source"? Isn't this almost close to using the same password on every site? I realize a physical secret is better than a password, but if someone gets their hand on your little FIDO device, do they instantly get access to all your accounts?
I've avoided getting a Yubikey because there's not an easy way to use it on my iPhone, sticking with TOTP. But that's a bit of an edge case. (iPhones lack NFC chips)
I think fundamentally most users don't understand anything more complicated than passwords. Passwords are easy. They make sense. A kindergartener understands the idea of a secret word that only they know.
Tokens, certificates, FIDO -- it's black magic. Therefore people don't trust it.
It has to be as easy and intuitive as passwords or it's a non-starter.
That's why the SMS codes (though insecure) are so popular. People understand "enter this number that I just texted to you"
Passwords are only easy if you're using them in an insecure fashion (sharing common passwords across multiple sites). Doing passwords right is actually really, really hard without the assistance of an external tool (password manager).
I get what you're saying though. Users are used to passwords, so moving to an alternative means of authentication will introduce a bit of friction. That said, I think that done right WebAuthn will actually be way easier to use than passwords. Users will just be able to sign in to their browser once, then use what is effectively single-sign-on for every site thereafter.
We're still quite a ways away from that point, but that's where we're headed.
> I think fundamentally most users don't understand anything more complicated than passwords. Passwords are easy. They make sense. A kindergartener understands the idea of a secret word that only they know.
I don't think it's that conceptually difficult to understand even for a layman.
The bare minimum understanding of web security is that authentication is the process of proving who you are (your identity). You can do it one of three ways (or a combination of them):
1. "Something you know" - Password, Background questions, etc.
2. "Something you have" - Yubikey, Smartcard, TOTP, SMS, email, etc.
3. "Something you are" - Biometrics
OpenID Connect is probably the most popular alternative to having a password for every single site. Especially on mobile, most apps usually have an option to sign up/login with your Google or Facebook account.
I'm still a bit bummed that OpenID (the original version) got lost to history. It's not really 'open' if you are handing over the keys to Facebook or Google.
What in the spec precludes this from being implemented in software?
[edit] Reading more of the spec it definitely seems like they meant for it to be possible to implement this in software. So while a physical FIDO device might be preferable, it shouldn't be necessary.
Does anyone else find these informal specifications difficult to digest?
The informative appendices link to papers on TPM and the like but it's hard to find a formal description of the protocol, or at least the sensitive parts, that could be independently validated or verified.
Has there been any work to formally verify/validate the design of this protocol that I'm not seeing?
You're not alone. I'm self-taught in english and it's not my first language. Although native english speakers have commended me I still find reading technical texts taxing.
They fall in the category of any academic text. Be it from a uni, research group, specfication manual. I did not receive formal education in English so I don't understand those formal words. Every other sentence there's something I have to look up and then I'm in a rabbit hole.
Actually same goes for my native tongue in some respect since I dropped out of school before reaching university.
I've still managed to make a career in IT and often desire to read technical specifications but feel helpless when I try.
My strategy so far has been to wait for an implementation in a language I can understand like Python, hopefully.
Formal as in Formal Mathematics -- a specification with a precise definition that can be verified by a model checker to have the desired safety and, if necessary, liveness guarantees.
That's... actually not as bad as I was expecting it to be. If you're willing to limit your audience to modern browsers only, the only holdout is Safari; and on that score, what else is new.
It’s actually included as an Experimental Feature in the preview version of Safari, so there’s some hope that it will be present in the mainline version before too long.
Its not just whether the API is available but whether its practical to use. I'm not sure which browsers recognize or support fingerprint readers, though all the implementations seem to support usb u2f.
Feels like a total failure to launch that the spec doesn't recommend the use of browser accounts as credential providers. Every single major browser has an associated web account with it (Firefox Account, Google account, Microsoft account, Apple id, etc) and could trivially use those accounts as authentication providers.
It's unsurprising this is the case: to be published as a Recommendation you have to demonstrate interoperable implementation experience.
The implementation report is at https://www.w3.org/2019/01/webauthn-report.html and shows Safari passing most of it, AFAICT. (Though it's based on Safari Technology Preview and is yet to ship.)
I got a YubiKey a year or so back and looked at this. It seems like Safari's holding out on a confirmed spec because before then it was a bit too Chrome-specific.
Readit News
https://auth0.com/blog/web-authentication-webauthn-overview-...
Sure if one is minimalism (using a few services) Once a storage needed (load of brain, password manager, paper etc.), the "just" goes away.
> without any entanglent to some app, device
Again If said storage needed, this is not advantage anymore.
Tokens, certificates, FIDO -- it's black magic. Therefore people don't trust it.
It has to be as easy and intuitive as passwords or it's a non-starter.
That's why the SMS codes (though insecure) are so popular. People understand "enter this number that I just texted to you"
I get what you're saying though. Users are used to passwords, so moving to an alternative means of authentication will introduce a bit of friction. That said, I think that done right WebAuthn will actually be way easier to use than passwords. Users will just be able to sign in to their browser once, then use what is effectively single-sign-on for every site thereafter.
We're still quite a ways away from that point, but that's where we're headed.
I don't think it's that conceptually difficult to understand even for a layman.
The bare minimum understanding of web security is that authentication is the process of proving who you are (your identity). You can do it one of three ways (or a combination of them):
I'm still a bit bummed that OpenID (the original version) got lost to history. It's not really 'open' if you are handing over the keys to Facebook or Google.
Deleted Comment
[edit] Reading more of the spec it definitely seems like they meant for it to be possible to implement this in software. So while a physical FIDO device might be preferable, it shouldn't be necessary.
Deleted Comment
The informative appendices link to papers on TPM and the like but it's hard to find a formal description of the protocol, or at least the sensitive parts, that could be independently validated or verified.
Has there been any work to formally verify/validate the design of this protocol that I'm not seeing?
They fall in the category of any academic text. Be it from a uni, research group, specfication manual. I did not receive formal education in English so I don't understand those formal words. Every other sentence there's something I have to look up and then I'm in a rabbit hole.
Actually same goes for my native tongue in some respect since I dropped out of school before reaching university.
I've still managed to make a career in IT and often desire to read technical specifications but feel helpless when I try.
My strategy so far has been to wait for an implementation in a language I can understand like Python, hopefully.
Having worked with a few different standards before, I was pleasantly surprised by how easy to understand and ergonomic (https://github.com/google/mundane/blob/master/DESIGN.md) the WebAuthn spec was.
English version. (It wasn't originally in English for me, but maybe it was autodetecting something?)
[0] https://www.w3.org/Press/Releases-2019#webauthn-rec
Feels like a total failure to launch that the spec doesn't recommend the use of browser accounts as credential providers. Every single major browser has an associated web account with it (Firefox Account, Google account, Microsoft account, Apple id, etc) and could trivially use those accounts as authentication providers.
The implementation report is at https://www.w3.org/2019/01/webauthn-report.html and shows Safari passing most of it, AFAICT. (Though it's based on Safari Technology Preview and is yet to ship.)