
Web Authentication: Proposed API for accessing Public Key Credentials - jtbayly
https://www.w3.org/TR/2018/CR-webauthn-20180320/
======
dang
Url changed from [https://www.engadget.com/2018/04/10/fido-w3c-web-
authenticat...](https://www.engadget.com/2018/04/10/fido-w3c-web-
authentication/), which points to this.

------
StavrosK
The article is a bit misinformative, with the biometrics red herring. Unless
I'm mistaken, this is Webauthn, the new standard that will allow devices to
authenticate using cryptographic keys that they have generated and stored,
it's kind of like supercharged U2F.

Basically, your phone and computer (or USB key) will be able to generate keys
and authenticate to each website uniquely, without the possibility of someone
stealing your password or phishing it/spoofing the site.

It's a fantastic improvement, imagine if you could log in to a site on any
untrusted computer just by plugging your USB key in, and you would be totally
secure again after you logged out of the site.

~~~
zAy0LfpBZLC8mAC
You cannot use an untrusted computer to reliably log out.

~~~
jessaustin
If, as GP suggests, you have to plug a USB device in to auth the first time,
why not just run the protocol through the device for every single HTTP
request? Then, if the user unplugged the device, future requests would fail,
right? I don't know if the protocol under discussion forbids that, but it
seems like an easy change?

~~~
djrogers
A USB device would only be one of many options - relying on it would be pretty
backward looking.

~~~
jessaustin
Other things would have other options. You might have a bluetooth or nfc
device that has a "momentary" button, that e.g. you have to press less than
five seconds before any particular web request.

~~~
filleduchaos
That's a straight path to frustration on today's web

------
throwawayReply
Fingerprints are usernames, not passwords (2013):
[http://blog.dustinkirkland.com/2013/10/fingerprints-are-
user...](http://blog.dustinkirkland.com/2013/10/fingerprints-are-user-names-
not.html)

edit: The original headline before being changed, "Web standard brings
password-free sign-ins to virtually any site", and contained a paragraph
espousing fingerprints in place of passwords.

~~~
Spivak
This meme needs to die. Fingerprints are a perfectly fine authentication
factor. They are unique enough and require effort to fake.

Consider a simple fingerprint USB vault which stores your keys:

* Factor 1: You must have physical possession of my vault.

* Factor 2: You must be me or have a convincing fake of my fingerprint.

Before we even think about a password I've already prevented almost all of the
attacks I'm likely to ever encounter against my accounts.

* I have made it impossible for someone to casually break into my accounts/device.

* I've created enormous distance between myself and remote attackers.

* I've eliminated password reuse and contained the effect of data breaches to the service that was breached.

* I've made it much more difficult for network operators to carry out MitM attacks since tokens are origin bound and the challenges are real-time with replay protection.

Yes in a forum of nerds you can point out that lifting fingerprints is
possible but if everyone switched to this simple U2F device the world would be
far far more secure. Passwords optional.

 _Then_ if you're worried about a more sophisticated attackers like corporate
espionage or governments you can add a password.

~~~
um_ya
The difference is you leave your password everywhere you go. Doesn't matter
how unique it is, if I leave a sticky note with a password everywhere I touch,
then it's not very good security.

~~~
r00fus
If you have something as sophisticated as TouchID, it's actually hard to
replicate a valid print. CCC did it in a lab situation (wine glass + latex
paint), how is a smear on a tabletop or mug going to be retrievable for a
sophisticated scanner?

~~~
mclehman
If I recall correctly, someone was able to fool TouchID a few years ago using
a fake print created purely from pictures of a German government official.

~~~
acdha
That was impressive but it's still something of an edge case: he used it to
register & unlock a phone but did not unlock _her_ phone and it sounds like it
required a photograph taken a few feet away at a press conference using a big
lens:

[https://www.youtube.com/watch?annotation_id=annotation_26842...](https://www.youtube.com/watch?annotation_id=annotation_2684251971&feature=iv&src_vid=pIY6k4gvQsY&v=VVxL9ymiyAU)

I think for most people convenience remains a win over the marginal increase
in risk — someone who can get that close to you can also use a hidden
camera/drone to watch you enter a password, steal your wallet/bag with two-
factor codes, etc.

~~~
r00fus
Given that YT link _ist im Deutsch_ I'm going to pass on decyphering it.

How does registering and unlocking another phone show that it would work on
_her_ phone?

I really don't think TouchID is at all riskier than even a 6-digit passcode. I
really still wish Apple allowed multi-factor unlocking though.

~~~
acdha
That’s the English translation but, yes, recovering a fingerprint which can be
used to unlock a test device doesn’t show it can replace the original. It’s
prudent to assume that the attacks will get better but I think this really
highlights the difference between broad and targeted attacks since so many
people are better off with the fingerprint unlock.

------
CiPHPerCoder
> [https://www.w3.org/TR/2018/CR-webauthn-20180320/#sctn-
> cose-a...](https://www.w3.org/TR/2018/CR-webauthn-20180320/#sctn-cose-alg-
> reg)

I'm not feeling great about these algorithm choices. Namely: RSA with
PKCS1v1.5

See also: [https://robotattack.org](https://robotattack.org)

EDIT: Also, elliptic curve digital signatures with a random nonce (here, "r")
instead of deterministic nonces makes me feel itchy.

[https://fidoalliance.org/specs/fido-
uaf-v1.1-id-20170202/fid...](https://fidoalliance.org/specs/fido-
uaf-v1.1-id-20170202/fido-ecdaa-algorithm-v1.1-id-20170202.html#ecdaa-sign)

------
Ajedi32
Link to the actual standard: [https://www.w3.org/TR/2018/CR-
webauthn-20180320/](https://www.w3.org/TR/2018/CR-webauthn-20180320/)

The "Use Cases" section in particular does a pretty good job of explaining how
this would work from a user's perspective: [https://www.w3.org/TR/2018/CR-
webauthn-20180320/#use-cases](https://www.w3.org/TR/2018/CR-
webauthn-20180320/#use-cases)

------
parliament32
Client-side TLS certs have been a thing approximately forever, yet everyone is
hesitant to use them because... installing a cert in your browser is hard, I
guess?

Many corporations and agencies use certificates either as the primary (only)
auth method, or as supplementary auth. For example, DTrade, the US defense
export licensing system:
[http://www.pmddtc.state.gov/DTRADE/index.html](http://www.pmddtc.state.gov/DTRADE/index.html)

We use them at work and they work great. Pretty much instant auth to any
internal site with no shenanigans.

~~~
lawl
They are also not trivial for webdevs to implement, since the webapp usually
doesn't terminate the TLS connection itself.

~~~
GordonS
The web server usually handles that side of things.

The big problems you have are private key generation, certificate
distribution, revocation, renewal, and guiding your users on how to install
the damn things.

~~~
orf
So now your authentication logic lives in your Nginx config, a rather odd
language with it's own fair share of quirks. That's not great and it's not
where the logic conceptually fits.

~~~
slrz
You generally setup the reverse proxy to pass the required information to the
backend via some trusted mechanism (e.g. HTTP headers not settable through
client requests).

------
blakesterz
This week's Risky Business has a pretty long segment on this:
[https://risky.biz/RB494/](https://risky.biz/RB494/)

I _think_ it's a less bad alternative for people using the same password on
everything. As many comments here already pointed out, it's not perfect. I
don't feel like I know enough about it to know just how good it will be for
the average person.

See also: that SQRL thing Steve Gibson has been working on for years?

~~~
tptacek
I've never talked to anyone who took SQRL seriously, or even seriously looked
at it for flaws. The problem with secure login isn't that you can't invent
some random ad-hoc crypto protocol to log into sites with; it's that what you
come up with has to be so credible that lots of sites, and eventually
browsers, will implement it. SQRL is not that.

~~~
Ajedi32
SQRL is actually a reasonably well-designed authentication system; certainly
better than passwords at least. But as you said, few if any sites ever
bothered to implement it. There's just no incentive for sites to adopt a new
authentication method when passwords already "work fine" from their
perspective.

Hopefully the web authentication standard won't suffer the same fate. It _is_
backed by several major companies (Google, Microsoft, Mozilla) so at least
they'll be able to kickstart adoption by implementing the API on their own
sites.

~~~
jiveturkey
SQRL has been debunked. Google quickly returns
[https://security.blogoverflow.com/2013/10/debunking-
sqrl/](https://security.blogoverflow.com/2013/10/debunking-sqrl/) but there
are plenty other critical reviews.

~~~
Ajedi32
Yes, I've seen that post. It's very misleading, to the point of being flat-out
wrong.

> Authentication and identification is combined

This is plain false. There's nothing in the spec that says you can't give a
site your email address, and there _is_ a built-in way to revoke credentials
in the spec.

> Single point of failure

This is dumb. Password managers have exactly the same flaw and nobody seems to
have a problem with that.

> Social Engineering attacks

This true, but only in exactly the same way that password managers are
vulnerable. (If the user is for whatever reason not using a browser plugin to
authenticate, _and_ you can trick them into entering their info on the wrong
site.)

~~~
jiveturkey
Thanks for a thorough reply. I'll take a new look at it, even though it's
pretty clear SQRL is long dead.

------
niftich
Hey look, client certs!

The primary innovation here is browser buy-in, and API hooks for onboarding to
make the UI/UX of the process suck less. This is a good thing.

~~~
tialaramex
Client certs always prove that niftich is niftich. This _might_ be fine, but
most people aren't comfortable giving the same credentials to their bank,
Facebook, and RedTube.

This thing has a masking step, so you always prove to any particular site that
you're the same person you were the last time you visited. But you don't
(deliberately) present them with any clue as to who that is exactly.

There's even a deliberate choice where though you can specifically identify
models of product [ e.g. "This is a Mattel Barbie brand authenticator" so that
in principle a bank could agree to use this standard but they only want to
accept official bank-branded tokens ] the specification says DO NOT put unique
serial numbers inside the tokens, if you want to distinguish them, make sure
only large runs are distinguished e.g. "Batman authenticator" versus "Barbie
authenticator" but never distinguish "Steve's authenticator" versus "Dave's
authenticator" so as to preserve the privacy mechanism.

~~~
emlun
Just to be clear: The tokens _can_ contain unique serial numbers in some
vendor-specific format - but they MUST NOT be in the attestation certificate,
so the WebAuthn API will never expose them to the server.

------
oliwarner
I'll start to relax when every forum and shopping cart doesn't demand I save a
password to create an account with them.

OpenID was supposed to help here. But even stalwarts like Stack Exchange are
backing off from it, leaving a handful of proprietary links and their own
OpenID provider.

Of course this is going to help with higher complexity authentication methods
(retinal scanners in the 2028 Macbook Pros?) but it's all for naught unless we
can patch every PHPBB and Magento clone to stop being so needy when it comes
to passwords.

------
startupdiscuss
Whatever system you come up with, we have to ask these questions:

1\. What if I lose my finger/password?

2\. What if someone else gets a copy of my finger/password?

In both cases, fingerprints seem to make things worse, not better. The
fingerprint is great if someone else has to be present to watch you put your
finger down.

------
slaymaker1907
Not sure if anyone has linked the Mozilla page yet, but
[https://developer.mozilla.org/en-
US/docs/Web/API/Web_Authent...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Authentication_API) seems to be a good guide for
developers.

------
not_that_noob
While I applaud the hard work the W3C group has put into this, and the
excellent spec, I can't help but think that they are solving a problem that
doesn't exist.

Attackers are much more likely to assume a user's identity and thus acquire
the user's certificates for such a system. That's how most compromises today
happen.

The central issue is verifying a claimed identity - not just at enrollment
time but also on every use. The spec waves that off to 'Authenticators' (see
below). But that's not a solution. If user authorization to certificates are
based off passwords, for example, then what prevents an attacker from taking
compromised data about me and using that to get access to passwords?

Don't get me wrong - this is good work. But I just think everyone seems to be
focussing on the wrong end of the stick.

=======================

 _User Verification_

The technical process by which an authenticator locally authorizes the
invocation of the authenticatorMakeCredential and authenticatorGetAssertion
operations. User verification MAY be instigated through various authorization
gesture modalities; for example, through a touch plus pin code, password
entry, or biometric recognition (e.g., presenting a fingerprint)
[ISOBiometricVocabulary]. The intent is to be able to distinguish individual
users. Note that invocation of the authenticatorMakeCredential and
authenticatorGetAssertion operations implies use of key material managed by
the authenticator. Note that for security, user verification and use of
credential private keys must occur within a single logical security boundary
defining the authenticator.

~~~
Ajedi32
It _does_ solve a real problem. Several actually: password reuse, weak
passwords, and phishing. If this catches on, it'll pretty much eliminate all
leading causes of account compromise on the modern web. That's huge!

However, as you said, it seems like the other piece of the puzzle (the
authenticators) isn't fully baked yet. U2F is one existing option, but that's
not really suitable as a password replacement all on its own (it's just "what
you have"). Hopefully Google, Mozilla, and Microsoft (all of whom contributed
to development of this standard) have some ideas for standard cross-browser,
cross-platform authenticators that provide the other authentication factors.

~~~
not_that_noob
It doesn't actually. If the authenticator expects passwords, then this simply
moves the problems you cite to another part of the system. These are the
sources of compromises on the modern web. It's a neat system - but it doesn't
solve the key issue.

~~~
Ajedi32
Doesn't really matter if the authenticator expects a password, because that
password _isn't_ what's used to authenticate to the site itself; it's always a
public/private key pair.

If the user decides to use 12345 as his password for a Web Authentication
authenticator that's obviously less than ideal, but still impossible to phish
(the browser validates the domain the user is on), infeasible to brute force
without access to the user's device (where the actual key pair is stored), and
impossible to compromise in a data breach (the site only has a public key).

~~~
not_that_noob
It's the weakness of single-sign on - if the authenticator is compromised,
then the attacker now has the key that controls access to all the keys.

~~~
Ajedi32
Sort of. Except the attacker has to compromise each user individually; there's
no centralized server to target as is the case with existing single sign on
services.

~~~
not_that_noob
This already happens - it's called spear phishing. Instead of wasting time
with multiple users, the attacker picks a high-value target. For example, if
you can get one admin, it's game over.

~~~
sowbug
In this thread, you keep moving the problem statement to cover a smaller and
smaller subset of the general problem of account compromise. This is exactly
what the attackers you're describing will do.

That's the point of this solution. If we can remove the vast majority of
account-compromise tactics and force attackers to achieve success only if they
"get one admin," then that's an incredible victory -- especially for the large
number of ordinary people who are not admins.

------
chrismorgan
What I would really like is a straightforward migration guide for those of us
already using the FIDO U2F JS API, to help people migrate in a backwards-
compatible way from the old, poorly-documented stuff to the new, currently
poorly-documented but very soon better-supported stuff.

So far,
[https://www.imperialviolet.org/2018/03/27/webauthn.html](https://www.imperialviolet.org/2018/03/27/webauthn.html)
is the closest; it’s good, but I’d love to have something with more
straightforward instructions—“so you currently use U2F? Change this to this,
that to that, do this to maintain compatibility and you’re roughly done”.
We’ll figure it out for FastMail, but if the migration is straightforward and
well-documented it’ll help all the web services out there to move sooner
rather than later, which as a _user_ I would very much like.

------
ReverseCold
Even better, hardware authentication token + second factor is password.
(something you have, something you know)

See [https://github.com/bitid/bitid/](https://github.com/bitid/bitid/)

It would also probably be easier/(or at least not harder) for people than
username and password. Just tell users to press the button and enter a
password to sign in.

~~~
jiveturkey
yes. this spec (u2f) makes the hardware part more feasible to implement
without needing to enter an OTP. thus enabling 2fa very widely.

~~~
emlun
It also thwarts phishing and MitM attacks (assuming the browser is not evil),
which OTPs do not.

------
kodis
The article is a bit light on specifics, but I hope that this (or something
like it) comes to pass. I'm not convinced of the security of the current batch
of biometric authentication schemes, but I have some confidence that the
organizations developing this standard know enough about what they're doing to
avoid the obvious blunders.

------
baybal2
What do they get from moving public key auth from tls to some kind of web api?

To me this looks like a duplication of efforts

------
welder
Whatever happened to BrowserID from Mozilla? [1]

[1]: [https://github.com/mozilla/id-
specs/blob/prod/browserid/inde...](https://github.com/mozilla/id-
specs/blob/prod/browserid/index.md)

~~~
y0ghur7_xxx
It was discontinued and died.

------
mozumder
Unfortunately, until Apple incorporates this into Safari, it's not going to be
usable. We'll have to wait and see what Apple announces at WWDC to see if this
is useful. FaceID+Password would be an excellent companion to this.

~~~
emlun
Apple does seem to be working on it:
[https://bugs.webkit.org/show_bug.cgi?id=181943](https://bugs.webkit.org/show_bug.cgi?id=181943)

------
Jayakumark
To test , use latest version of version , Fido U2F Key and go to
[https://webauthn.io/](https://webauthn.io/)

------
s2g
I'd honestly just rather get hacked on 99.9999% of sites.

I absolutely hate getting told to go get my phone or go to my email.

This also makes me a lot more paranoid about losing my phone.

~~~
nerdymanchild
You don't have to use your phone. In theory you may also use a Yubikey

~~~
btb
I had a yubikey. It died after a few months of simply lying on the shelf
behind me. No idea why, but havent exactly been a fan after that.

~~~
nerdymanchild
Did you get it replaced? Seems like it should have still been under warranty
after only a few months.

------
cfv
Brought to you by the same guys who decided giving opaque, untamperable access
to your browser by random external parties was a good idea.

I think I'll pass.

------
0x0
Is it the html <keygen> tag v2, done right?

~~~
geertj
From a very high level, yes, although this solves a wider range of problems.

------
jp_rider
How does the browser know what the relying party is? Does the website provide
a URL for the browser to communicate with?

------
madjam002
Would be nice if this could somehow integrate with GPG and scdaemon so that
you can use OpenPGP cards to authenticate...

------
Edmond
sounds like something i proposed a while back:

[http://blog.codesolvent.com/2015/07/why-not-signed-
password-...](http://blog.codesolvent.com/2015/07/why-not-signed-password-
authentication.html)

~~~
arnarbi
The origins of WebAuthn go back to
[http://www.czeskis.com/research/pubs/czeskis-phoneauth-
ccs12...](http://www.czeskis.com/research/pubs/czeskis-phoneauth-ccs12.pdf)

------
homakov
10 years after now, it is gonna change nothing. Cumbersome slowly developed
standard.

------
exabrial
Seems to overlap with U2F... can we extend that standard instead of rewriting
it?

~~~
Ajedi32
The Web Authentication Standard supersedes U2F:
[https://fidoalliance.org/fido2/](https://fidoalliance.org/fido2/)

------
eazel7
this reminds me to MS InfoCard/CardSpace
[https://en.wikipedia.org/wiki/Windows_CardSpace](https://en.wikipedia.org/wiki/Windows_CardSpace)

------
nerdymanchild
Can't wait to use my OpenPGP card to authenticate with websites.

------
jiveturkey
bit of a fluff piece for FIDO and Firefox. U2F already did what’s described.
This just formalizes the spec into www.

[https://www.w3.org/Submission/2015/SUBM-fido-web-
api-2015112...](https://www.w3.org/Submission/2015/SUBM-fido-web-
api-20151120/)

~~~
jiveturkey
oops that was the 2015 version. the official standard is the same and just
adds a “userHandle”. IOW this is not news.

------
ggggtez
Misleading. Most sites would be foolish to use a 2 factor(like a fingerprint),
but not a password.

~~~
imron
Indeed, especially when most computers and phones are literally _covered_ in
the target fingerprints.

~~~
nodesocket
The issue is not physical breaches by "dusting" fingerprint.

------
mkolodny
tl;dr: Instead of having a password for each website, we'll use our phones'
built-in security (pin, pattern, etc) to log into websites

------
bitrazor123
I have been hearing alternate sigin-in methods in last good 10 years , from
biometrics to typing behaviour to human behavior and what not. Even a 99%
accuracy is not enough for a security tech to mature, specially when it comes
to credential management

~~~
quantized1
Agree to disagree. These might not be production ready, but any novelty has to
start somewhere before it becomes matures enough for wider adoption.

