
W3C approves WebAuthn as the web standard for password-free logins - markoa
https://venturebeat.com/2019/03/04/w3c-approves-webauthn-as-the-web-standard-for-password-free-logins/
======
chrisweekly
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:

[https://auth0.com/blog/web-authentication-webauthn-
overview-...](https://auth0.com/blog/web-authentication-webauthn-overview-
demo-tool/)

~~~
dawnerd
Can I just say I detest magic link emails that don't offer me a way to just
use my password manager?

~~~
elliotec
How would a magic link email be used with a password manager?

~~~
dawnerd
im talking products like notion that only support magic links (or google auth
I guess but I’m not doing that). Slack does it right. You can use a magic link
or use your password.

~~~
mderazon
I think Medium does that

------
Canada
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.

~~~
dontbenebby
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)

~~~
ak217
I agree it's annoying. They're working on it, but they should have really
enabled it sooner. There's no technical reason, iPhone has the necessary NFC
hardware. [https://www.wired.com/story/yubikey-lightning-ios-
authentica...](https://www.wired.com/story/yubikey-lightning-ios-
authentication-passwords/)

~~~
velosol
Their main page for mobile heavily implies they are already there with
iPhone/NFC.

[https://www.yubico.com/products/yubikey-for-
mobile/](https://www.yubico.com/products/yubikey-for-mobile/)

~~~
ak217
Actually, you're right - that capability has apparently been available since
last year: [https://www.yubico.com/2018/05/yubikey-comes-to-iphone-
with-...](https://www.yubico.com/2018/05/yubikey-comes-to-iphone-with-mobile-
sdk-for-ios-and-lastpass-support/). The link I cited is for lightning-
connected Yubikey hardware, which is supposed to come out this year.

------
ams6110
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"

~~~
Ajedi32
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.

------
vbezhenar
I don't understand how does it work. If I'm using just desktop and don't have
mobile phone or any specialized hardware, I can't login?

~~~
arianvanp
Correct. You'll need a FIDO key to log in in that case

~~~
eikenberry
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.

~~~
akerl_
It looks like
[https://github.com/github/SoftU2F](https://github.com/github/SoftU2F) would
work for that.

I believe Chrome’s dev channel also has experimental soft webauthn support.

~~~
Rafert
Currently, it does not because the browser aborts when it loses focus:
[https://github.com/github/SoftU2F/issues/51](https://github.com/github/SoftU2F/issues/51)

------
agentultra
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?

~~~
INTPenis
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.

~~~
_asummers
They're commending you because your English is terrific =) Learning a language
is tough work, but if you didn't say anything I would have had no idea.

------
ak217
Shameless plug of a WebAuthn relying party (RP) library that I implemented
recently (Python server, JS client):
[https://github.com/pyauth/pywarp](https://github.com/pyauth/pywarp)

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](https://github.com/google/mundane/blob/master/DESIGN.md))
the WebAuthn spec was.

------
detaro
W3C press release: [https://www.w3.org/2019/03/pressrelease-webauthn-
rec.html](https://www.w3.org/2019/03/pressrelease-webauthn-rec.html)

~~~
wccrawford
[https://www.w3.org/2019/03/pressrelease-webauthn-
rec.html.en](https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en)

English version. (It wasn't originally in English for me, but maybe it was
autodetecting something?)

~~~
Outpox
It was in my native language (French). According to the "Translation" link[0]
it's available in English, Japanese, Chinese and French.

[0] [https://www.w3.org/Press/Releases-2019#webauthn-
rec](https://www.w3.org/Press/Releases-2019#webauthn-rec)

~~~
gsnedders
It uses HTTP content negotiation, based on the Accept-Language header.

------
tofflos
[https://caniuse.com/#search=webauthn](https://caniuse.com/#search=webauthn)

~~~
smacktoward
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.

~~~
zanny
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.

~~~
michaelt
That would make it difficult to change browsers, wouldn't it? Or indeed to use
different mobile and desktop browsers?

------
Ajedi32
Almost there; now we just need some cross-platform implementations with synced
credentials, and support from a couple major sites. Ideally some password
managers will step in and implement support, and Google will add support to
their own login flow as a primary authentication factor.

~~~
edraferi
Agree. Credential syncing is important.

Use case: I create an account using using a Yubikey on my desktop, then want
to access that account from my mobile phone using a fingerprint. How does the
website know I'm the same person?

Keybase has a nifty personal web-of-trust for this stuff, but (A) that ties
you to a single strong identity and (B) you can't really use that identity
outside of their services.

------
madjam002
Still waiting for Google Chrome and Firefox to support User Verification in
the form of PIN prompts and Resident Keys for true passwordless login (at the
moment WebAuthN in Chrome is basically just 2FA, no option for Passwordless).

Hopefully soon!

~~~
agl
Early support should be appearing in the coming weeks on Canary channel when
run with --enable-features=WebAuthenticationPINSupport

------
eximius
Somewhat random thought: is Challenge-Response sufficient or should it be
'Challenge-Challenge-Response' so that the client only answers a challenge it
requested? Otherwise, what's to stop an XSS attack on page A from effectively
MITM page B by overriding the event listener for the login on page A, asking
to sign for page B, then exfiltrating the response?

EDIT: looks like the dialog attempts to give you some information, but it
doesn't say WHICH profile on the domain and people could certainly not pay
attention to the domain in that prompt (I had to check if it existed because I
hadn't noticed).

~~~
solatic
From what I understand, the way that FIDO defeats phishing is that it signs a
response on the basis of the presented domain. If a phisher stands in the
middle with a domain looks similar to human eyes to the legitimate domain,
then the attacker is returning to the legitimate domain a response that was
signed for the wrong domain, causing origin to reject the response.

If your site makes it even remotely possible to have an XSS attack on the
login page (by not being a separate page with no user-provided input apart
from the login credentials) then you're doing login pages wrong to begin with.

~~~
eximius
I'm not sure this addresses my point.

> If your site makes it possible to XSS the login page, you're doing login
> pages wrong.

Agreed, but the point was that a DIFFERENT service might be vulnerable and
have XSS on their page which allows an attacker to request credentials for the
real target. Your service isn't hacked, your users are.

> signs a response on the basis of the presented domain

This might do it, depending on what this means... Does this mean that if my
address bar says `www.serviceA.com` that I include that domain in the
response? Then if I asked the client for their credentials with a challenge
and `rawId` (I think that's what identifies the relying party, IIRC) matching
`www.serviceB.com`, it's possible that `www.serviceB.com` can reject the
MITMed response because the attestation has the wrong domain. This is similar
to JWT implementations only verifying the signature is valid and not checking
that the signature type is the kind expected (i.e., not none). So, a weakness
but nothing fatal.

I am curious how that works. I'll need to try it out.

------
mgoetzke
If only Microsoft hadn't chosen to use the code-name Hailstorm for its
authentication proposal back in the days (and generally had a better image and
a more open approach etc). Would have alleviated a lot of the pain earlier.

~~~
smacktoward
Hailstorm wasn't really the same thing. It positioned Microsoft as a
centralized identity provider, with MS holding all the user data and everyone
else just connecting to proprietary Microsoft online services to check if the
user was who they said they were. Kind of like Facebook Login, but built
around 2000s-era-trendy technologies like XML and SOAP instead of JavaScript
and JSON.

It's hard to see how Hailstorm wouldn't have run into the same issues people
have today with Facebook Login, the big one being that it's maybe not awesome
to have a gigantic, notoriously ethically-challenged competitor sitting
directly between you and your users.

~~~
mgoetzke
yeah i mixed that up, I meant CardSpace as was pointed out. Still a no-go for
other reasons though.

------
pier25
So what happens if you lose one of those USB devices?

Can you use multiple USB devices on the same site?

~~~
michaelt
OK, so here are the options I've seen people deploy for 2FA:

1\. Force users to register two U2F tokens. Google's 'advanced protection'
requires this.

2\. Have users print out one-time-use recovery codes and put them somewhere
safe. This is what Google does without 'advanced protection'.

3\. Require the user to provide a cell phone number, thus offloading the
problem to cell phone companies, introducing all the insecurities that result
from that. This is what Apple does (as far as I can tell)

4\. AWS is similar, but requires both an e-mail and an automated phone call.

5\. Github delegates 2FA recovery to Facebook, via their "Recover Accounts
Elsewhere"

6\. Facebook allows the user to designate 'trusted contacts' who can get a
code they can give to the user in person or over the phone.

7\. Have the customer contact customer services, who follow a process
companies are cagey about disclosing.

8\. In corporate settings, just have them visit helpdesk in person.

~~~
mrhappyunhappy
#2 sounds most appealing. I live in Japan and don’t have a reachable phone #.
Wife and I simply FaceTime if we need anything. Otherwise I have no mobile
means of authentication. There have been several occasions where I simply
couldn’t use the service because I could not authenticate via a phone number.
I feel that companies that force this method of authentication have never
considered my use case and could care less if they lose me in the signup
process. Too bad. I for one actually have the money to pay them, but hey, if
you don’t want it that’s fine with me.

------
wccrawford
The last time I saw 2fa and fido talked about on here, someone recommended a
set of 2 keys, but they ones they recommended are now out of stock.

Does anyone have a recommendation with the reason?

Thanks.

Edit: _With_ the reason. Jeez, what a typo.

~~~
tialaramex
I can tell you that I own a couple of off-brand devices and a blue Yubico
"Security Key".

But rather than specifically recommend things I will tell you what I believe
you should care about:

1\. Does it actually connect to things you authenticate on? If you always
authenticate a Mac Book Pro with only USB C ports, then the USB-A Security Key
is stupid because it'd need an adaptor. For physical connections if it shows
the connector you can feel comfortable, this isn't 4Gbps video it either works
or it doesn't. But for stuff like Bluetooth, find somebody who has actually
seen the thing you want to use working.

2\. For the primary device (if you don't have them identical) be sure how you
are going to carry it. Will it go on your key ring, or in your wallet? If you
have to carry an extra device and you're someone who has never owned an
umbrella for more than a month, that's futile, they're too tiny to rely on
getting them back but too expensive to throw away - pick something you won't
lose.

3\. Robustness. Again for the primary device, the Yubico key I have (USB-A
one) has good reputation here, with people leaving them in jeans pockets
through a wash or dropping them onto concrete floors without trouble. Others,
even from Yubico, vary, you may be super clumsy or not.

Beyond that there are some technical things you could decide you really care
about, hardware bugs, but none of them are exactly show stoppers that I've
seen. And there are extra features, that Yubico device I own does FIDO2, which
means it could be a true password _replacement_ not only a second factor. But
I think that feature has even less chance of taking off than WebAuthn itself,
so I didn't rate this in choosing the device.

------
Grue3
>Users log in with simple methods such as fingerprint readers, cameras, FIDO
security keys, or their personal mobile device.

Neither of these methods are simple. I don't have a camera or fingerprint
reader, idk what is FIDO security key or how to get one, and mobile phone can
be lost or cease working at any moment so it's not a reliable method of
authentication.

~~~
mgiannopoulos
So what is your suggested simple, reliable method of authentication? Does one
exist?

~~~
Grue3
A password sent over an encrypted connection and hashed+salted on the backend?
It's an extremely reliable and proven method that has been used for decades!

~~~
toyg
Totally secure against data breaches and phishing, as we've seen over and over
again.

Oh wait...

------
cm2187
How easy will it be to implement? We should keep in mind the most dangerous
guys out there store passwords in clear text in databases and other amateurish
rookie mistakes. Having _easy to use_ / _impossible to f__k up_ libraries for
every major platform is going to be critical.

~~~
eximius
There are two methods, IIRC. `get` and `create`. Everything is done with
Challenge/Response with the browser handling the Private Stuff. It's hard to
mess up, at a glance.

You ask the browser to create an asymetric key pair. It returns the public
key, which the server saves. On login, you provide a challenge to the browser
to sign using the private key from earlier. It returns the signed message and
the server verifies the signature.

~~~
mathnmusic
What if the user is trying to login via a device different from the first one?

~~~
tialaramex
I can't tell what "a device" means here.

If you mean "what it I only used Security Key A to register, but now I want to
sign in with Security Key B?" the answer is that you can't, that's the wrong
key. Register all the keys you want to use.

If you meant what if I registered with my Pixel phone and now want to sign in
on my Windows PC, that just works fine. The client "state" lives in the
Security Key (actually there is no state whatsoever in affordable designs),
it's very clever cryptography.

------
aboutruby
Working group's repo:
[https://github.com/w3c/webauthn](https://github.com/w3c/webauthn)

------
dustinmoris
I was saying for a long time that a new protocol for a biometric driven login
scheme should become the new default. We use biometrics to log into our phone,
then a password manager uses the same biometric to authenticate on the same
device to log me into a website by auto populating the username + password for
me. Afterwards I'll get a 2FA confirmation on the same device which again I'll
have to confirm via the same biometric. Instead of having so many moving parts
which all boil down to authenticate via a single vector (my fingerprint or
eye) on a single device we might as well have a new auth scheme and get away
with insecure passwords and expensive password managers and replace them all
with a new biometric driven login scheme.

Yes, there are still some issues that biometrics don't solve, but they should
not be a concern to most websites. If everything authenticates me via my
AppleID (which uses FaceID or Fingerprint) then I only need to remember one
password for Apple - which is just the same as remembering one password for a
third party password manager - except it's overall much safer and better for
me as a user as I don't have to upload all my online identities to yet another
third party that I don't know anything about (= password managers).

~~~
deadmetheny
Biometrics are just fine as a username or one factor of a MFA, but they are
terrible for usage as a password due to the simple fact that if they are ever
compromised, they cannot be changed.

~~~
dustinmoris
The truth is though that everyone is using biometrics to log into their device
which controls everything from emails, to password managers and 2FA codes.
Does it mean if your fingerprint gets compromised that you'll be unable to use
the biometric feature of any device for the rest of your life?

It's a good point which you raise, but ultimately biometrics will be the best
way to authenticate someone. It might have to evolve and get smarter and
better, but one day if someone is able to reproduce all your unique attributes
of who you are then nothing will probably hold them back to reset your
password manager, email and what not either. They will socially engineer
whatever they need and even when a human will verify that you are you they
will probably be able to provide enough believable evidence at which point it
doesn't matter anymore if they hacked a biometric login or socially engineered
your password manager.

~~~
acdha
> The truth is though that everyone is using biometrics to log into their
> device which controls everything from emails, to password managers and 2FA
> codes. Does it mean if your fingerprint gets compromised that you'll be
> unable to use the biometric feature of any device for the rest of your life?

No, because the device is only using that to protect local storage and
anything which leaves the device is using strong keys which can be rotated. If
they don't have the device, the fingerprint doesn't matter. If they do have
the device (and are within the timeout period, etc.), it's like any other
credential compromise: you get a replacement, rotate passwords, etc. but the
replay value is sharply capped because at no point is a network service
depending on the component which can't be changed.

(If you have an attacker who gets a scan of your fingerprint/face and keeps
stealing phones you need a restraining order; that's reasonably outside of the
threat model for consumer devices)

This is also important since there's a subset of users who won't be able to
use biometrics for some reason and the decoupled approach avoids making it
impossible for them to use.

------
roobs
I moved from primarily using a MacBook Pro to an iMac Pro a few months ago,
and have struggled to find a non-awkward FIDO U2F key due to the ports being
on the back. I'm really looking forward to a decent range of BLE U2F keys that
are supported on Desktop and Mobile.

~~~
lucascantor
I've previously seen (but never used) this product to make an iMac USB port
accessible from the front:
[https://www.bluelounge.com/products/jimi/](https://www.bluelounge.com/products/jimi/)

------
MrStonedOne
tl;dr: Every downside to 2fa is out of scope, so this doesn't solve them, and
doesn't require sites solve them.

It then suggests using this as both factors.

Most of all is reliability.

all "Something you have" based factors have one key issue, reliability.

Backup codes are not a solution, I'm not going to have those when i'm at a
friends house and get an alert the server is dead but i left my token at home.

Customer service is not a solution, its hard getting me to change my address
in the millions of places that have it, now I have to call up, to change my
token, because I lost it and have no idea where the fuck i put the backup
codes? Across the millions of websites I have an account on? Where each
provides their own backup codes?

Backup tokens are barely a solution. In that they only work once, lose your
backup token and you are back to the above. At the least you now have to buy
another one to become the new backup and go and load it on to all of your
sites.

I can't lose, break, forget at home, or otherwise invalidate a password. I can
forget it outright, something we know a lot of about, and something we have
workflows setup to deal with, some better than others, but I can't just one
day lose it and get locked out of _everything_ , I would have to forget all of
my passwords simultaneously to do that.

2fa for people who care about it seeing adoption: cloneable tokens. I
shouldn't need to re-setup my token across every site when it lose it. Habadab
about security all you want, as long as this is a barrier to entry it will
stay a barrier.

Also, with fancy crypo, it would be piss easy to make a token key base where
each token had its own key and that key can be revoked, but in a way where all
tokens work out of the box once you add 1 to a site.

------
mderazon
This will make sharing accounts between people much harder

------
n1vz3r
Is it only me or at first glance this VentureBeat article looks like popup-
ridden page from late 90s?

[https://imgur.com/a/vjGuFKs](https://imgur.com/a/vjGuFKs)

(yes, I know it's off topic)

------
morningmoon
As long as websites support password reset using email, anything but OTP sent
to email is unnecessary and over complicated.

------
Brian_K_White
sqrl

~~~
geuis
You're being downvoted because the comment isn't really adding anything to the
discussion because its so short.

What Brian_K_White is referring to is SQRL by Steve Gibson from GRC.
[https://en.wikipedia.org/wiki/SQRL](https://en.wikipedia.org/wiki/SQRL).

Its an alternative simpler secure protocol that has been in development for a
few years that is frequently discussed on the Security Now podcast.

~~~
ChrisSD
Steve Gibson has been promoting his solution for years but as far as I'm aware
security professionals have yet to see it as a serious alternative.

~~~
tialaramex
SQRL is a half measure, like SMS-TOTP it barely raises the bar because it
doesn't solve a key real problem we actually see happening in the wild and so
that would just happen more.

If site A is protected by SQRL, and I'm a bad guy, I can just live phish sign-
ins for site A using SQRL from my phishing site, site B. The users all believe
(as with other phishing attacks) that they're being asked for credentials by a
legitimate site and so they provide them with SQRL, and I'm in.

This (very common and fully automatable) trick doens't work on WebAuthn,
completely defeating phishing. This is because the fundamental idea in
phishing is "Humans are idiots, fool the human into mistaking site A for site
B". In WebAuthn the credentials are mechanically derived from the site you're
on, so for site A they will always be site A credentials, and for site B, site
B credentials. Convincing page design, an urgent email "from the boss", clever
use of IDNs to fake the URL, those fool the human but not the machine, and the
human is taken out of the "what site is this?" decision by WebAuthn.

But the human is left _in_ the loop in another way that leverages our
strengths. WebAuthn requires a physical interaction, typically a button press
by the human. So a hypothetical attack that takes say, 50 million
authentications, cannot work because the human will not press the button 50
million times while you do the attack. They'll get sick of it and go on
Twitter to moan instead.

~~~
tatersolid
SQRL protects against phishing by using the site’s URL to generate a per-site
Curve25519 keypair on the fly.

Same anti-phishing properties as being discussed here.

SQRL also has key revocation and rotation, but ultimately places responsibily
for keeping backups of revocation codes on paper to the end user.

But since you only need to do this once for your SQRL master secret, and not
for every damn site, it’s a lot more likely to happen in practice.

~~~
tialaramex
Nope. SQRL assumes that phishing simply won't work. Users are going to be
shown example.com and realise that's not right and abort. That's their
"protection". But phishing does work, people have tested. Some users notice
the domain name is wrong. Some don't. All press on anyway.

Why? Because Humans have a psychological problem that makes them bad at giving
up. We need to explicitly train safety critical people to go "Oh, this isn't
working. I will now report that I failed" rather than keep trying. In normal
people the drive to press on is almost unstoppable.

Hence "brick wall UI" design for things like HSTS. If you give humans two
options, destroy everything versus admit defeat, they pick destroy everything,
every single time. So we changed the UI to not have options. "Defeat"
announces the UI. And, defeated, the human gives up and doesn't destroy
everything. Hooray.

~~~
tatersolid
SQRL does not give the real identity to a phishing site. Full stop.

Now a phishing site can do a fake SQRL login, accepting any credentials. But
the client will send a different identity (derived keypair) with no
information linking to the real identity, so the phisher will have no
information with which to persinalize their fake site.

The user might press on anyway and divulge some sensitive data if the fake
site is really convincing. But the phisher cannot use any credentials passed
to them against the “real” site.

WebAuthn does NOT solve this “look-like site exists and accepts any
credentials” problem either, nor does any other _authentication_ mechanism.

The only protection against against what you describe is preventing
registration of look-alike domain names entirely, and ensuring all DNS is
secured with DNSsec or TLS. Good luck with that; it’s been tried.

------
MrStonedOne
[https://www.troyhunt.com/heres-why-insert-thing-here-is-
not-...](https://www.troyhunt.com/heres-why-insert-thing-here-is-not-a-
password-killer/)

~~~
tlholaday
Troy Hunt writes ...

> I'm referring to passwordless solutions that involves things like QR codes,
> pictorial representations, 3rd party mobile apps, dedicated hardware devices
> or "magic" links sent via email.

Which of these is AuthN, in your view?

Edit:

Troy Hunt also writes ...

> WebAuthn has the potential to be awesome, not least of which because it's a
> W3C initiative and not a vendor pushing their cyber thing. But it's also
> extremely early days and even then, as with [insert things here], it will
> lead to a change in process that brings with it friction. The difference
> though - the great hope - is that it might redefine authentication to online
> services in an open, standardised way and ultimately achieve broad adoption.
> But that's many years out yet.

.., so perhaps the many years have passed.

------
AnaniasAnanas
What does this solve exactly? We already have client-side certificates in TLS,
am I missing something?

~~~
tialaramex
Aside from the awful UX of client certs, which we could imagine being fixed,
FIDO tokens are very narrowly conceived to solve the exact second factor
problem - and nothing else.

If you do client certs you've got this whole identity thing baked into the
certs. But the FIDO token doesn't have an identity, it only knows how to prove
it's still the same FIDO token you had before. So that's immediately much
better.

If I use a client cert to sign into GitHub and Facebook, it's a matter of
moments for that to be correlated. If I share the client cert with my sister
or a colleague, again easily correlated.

But with WebAuthn there's nothing to correlate. The only way to check that
Bill and Suzy are using the same FIDO token is to wait until say Bill tries to
log in, and ask his token to prove that it's still Suzy's token. This requires
a physical interaction (e.g. button press) from Bill. If the guess was wrong
you learn nothing but Bill notices it didn't work. So, maybe, if you're nearly
certain but just want to be 100% that could work, but ordinarily it's not
viable at all.

~~~
Freak_NL
Also with a decent WebAuthn implementation (e.g., FIDO U2F hardware tokens, or
using a TPM), the private key material cannot be copied by a compromised
device, or even by someone with direct access to the hardware (unless they
actually disassemble the hardware with quite professional hardware).

Client-side certificates are a great technology, but you can copy the
certificates without the owner knowing it. Getting the password is just a
matter of social engineering or (further) compromising the device. It beats
plain username plus password though!

~~~
MrStonedOne
You tout it as an upside that it can't be copied.

But its really not.

How to prepare for losing tokens is the major barrier to entry for 2fa, and it
will be why it never sees mass adoption.

