
Web Authentication API - Jaruzel
https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
======
tptacek
For people confused about what this is: it's basically the de facto cross-
browser standard for U2F security keys like Yubikeys.

~~~
Ajedi32
More than that. Because it's an open standard it can be used with other types
of authenticators, like password managers and platform-level security keys.
There are also extensions allowing sites to prompt users for explicit
authorization for a specific action. (e.g. "do you want to send $20 to xyz?")

In short, this could replace passwords for web authentication entirely.

~~~
pc2g4d
If I'm not mistaken, the browsers themselves could act as "authenticators" and
help people manage credentials in software.

~~~
jonny_eh
Exactly. Authenticate with your Google account on chrome, iCloud account on
safari, or Firefox account on Firefox.

------
cornholio
I wonder if this API can be coaxed into providing a method of authentication
for "the other" 99% of people and use cases, without a hardware token and in a
device-independent fashion, _using passwords only_.

That may sound contradictory or that it misses the point, but let me explain.
The password can be used to locally decrypt a secret key that is stored on the
server at registration time, and that is retrieved based on the username
provided. What this achieves is a login system that covers the way social
login/Facebook/OAuth is used, without giving any power to a 3rd party. The
password never leaves his machine and the user is not dependent on any
particular hardware or keyring.

So for all those "I can't trust this website with a secure password / I can't
be bothered to signup" cases, you will have a strong authentication scheme
that is as secure as your (salted and stretched) master password, and where
you are guaranteed that a compromise on one of the sites does not spill over
to the rest. Unless you choose to reuse a username, your identities will be
independent and unlinkable, unlike any social login scheme, preserving
privacy. The user complexity is similar to what regular people already know,
usernames and passwords - you can even safely reuse a strong password. The
essential difference is that you should trust only your device / browser with
the password, not the site.

~~~
icebraining
Seems like in that scheme anyone can retrieve the encrypted secret without
authentication (just by knowing the username), and then try to brute-force it
at will.

~~~
cornholio
In a real world implementation this can be easily avoided by breaking the
retrieval query into a challenge-response like:

    
    
      retrieve_salt(username)
      retrieve_keyfile(username, encrypt(streched_password, salt, server_name))
    

So the offline, parallel crack turns into an online, serial and rate-limited
bruteforce. The salt and password derived shared secret are established at
account setup time and after any password change, which the browser must
support too.

This still has some imperfections related to replay susceptibility, but my
point isn't to design a protocol, rather the principle of a thing that could
make social login obsolete and stone-age.

~~~
Ajedi32
So now the server needs to store a copy of your stretched master password? How
is it supposed to know whether the value of `encrypt(streched_password, salt,
server_name)` is correct?

Why not just use public key authentication, like the Web Authentication
standard already does?

~~~
cornholio
>How is it supposed to know whether the value of `encrypt(streched_password,
salt, server_name)` is correct?

By comparing it to the static value stored at account setup time. The server
trusts your shared secret just like it trusts your public key - establishing
the identity of a public key is a different problem with various solutions,
CAs, WoT, directory servers etc. The idea here is to move from plain
authentication (user/password) to a public key system without carrying the key
material around, but deriving it when needed from your password.

~~~
Ajedi32
So the server stores a copy of your encrypted keyfile, salt, and the result of
`encrypt(streched_password, salt, server_name)`?

That's better, but still allows malicious sites (or anyone who compromises the
database of a site you have an account on) to brute force your master password
offline. Slightly better than reusing passwords since there's no danger of
sites using a weak hash algorithm or storing your password in plaintext, but
still not great.

IMO if you _really_ don't want to carry the key material around (which _does_
necessarily reduce security btw, as you're going from "something you have" \+
"something you know" to just "something you know", which is easier to steal
and inherently susceptible to brute force), then it'd be much simpler to just
derive a private key from `(user password, site id)` and use that with
WebAuthn.

------
franciscop
Finally! I have a design concept that I wanted to propose but never got around
it which would be very similar or even the complement, but without all the
security details that I do not know how to do and that this API is strong on:
[https://jsfiddle.net/franciscop/qj4g3rz8/](https://jsfiddle.net/franciscop/qj4g3rz8/)

The browser could store several data points for each field so you can choose
from a dropdown OR different user profiles so you can switch from "Francisco
the freelancer" to "Francisco the open source guy" in the drop of a beat. Or
per window to do both at the same time if that's your thing.

But anyway, this new Web Authentication API is really, really awesome to
remove passwords forever. Now we need the last one, which would be closer to
my design concept to even remove the manually adding all those fields: Web
Identity API.

------
Ajedi32
This is going to be _huge_ for the security of the average web user once it
starts getting widespread adoption.

Credential phishing, password reuse, credential stuffing, and weak passwords
are all about to be a thing of the past, at least insofar as the web is
concerned.

~~~
dmortin
Doesn't this mean that if the authenticator is cracked then all of your
accounts are revealed and become vulnerable?

Compared to the situation today when if one your passwords is cracked they
can't immeidately access your other accounts.

~~~
Ajedi32
Stealing Web Authentication keys from a hardware token is a significantly
higher bar than phishing you or brute-forcing your password hash from a
database leak. At the very _least_ the attacker would first have to compromise
your machine with malware, at which point they could easily get access to all
your password-protected accounts anyway with a simple keylogger.

~~~
dmortin
What happens if you lose your hardware token (or it gets stolen, ec.)? Is
there a way for then to access your accounts?

~~~
StavrosK
Ideally (and hopefully this will be doable, as I don't see any impediments),
you can have Bitcoin-wallet-style seed generation that you can back up onto a
piece of paper and store it somewhere safe.

I really hope my Ledger Nano S becomes WebAuthN-compatible, as it can already
be used as a U2F key.

~~~
tialaramex
Yes, for a device as complicated as the (~ $100) Ledger Nano S I don't see any
reason they couldn't support that functionality.

Most people will be using much cheaper, dumb authenticators which aren't going
to have the capability to read and update the keys, they would be expected to
replace their authenticator altogether, not try to clone it if there's a
problem.

------
darkhorn
Can you extract domain names and usernames from the U2F devices? Like if
someone wants to learn what sites he is visiting and his usernames?

~~~
tialaramex
In practice, no, the tokens are _way_ too dumb to remember anything like that.
They're using an old cryptographic trick to appear much cleverer than they
really are.

During enrollment they present the server with a public key, and a magic
cookie, both of which it stores. In subsequent authentication, the server
sends them back the cookie, and some random data, which the token then signs
to prove it still knows the private key, the server can check that because of
the public key it has.

But in practice the key pair never actually lives inside the token - it makes
the key pair during enrollment, and the "magic cookie" was actually its
private key encrypted using a secret key only the token knows. So the token
has no writeable storage, just ROM and a little bit of DRAM. Some tokens might
have a tiny amount of flash to e.g. store a counter or a user chosen PIN to do
PIN authentication instead of a one touch auth, but they aren't storing a
bunch of keys, or domain names, or email addresses.

~~~
konschubert
This is so cool.

This feels so much like cheating that I was sure it must be flawed, but I
couldn't come up with any weakness.

I conviced myself that this is possible by considering the method of using a
different permutation of the same key pair on each website and storing that
permutation, encrypted, in a cookie.

Cryptography is awesome.

------
danellis
Since TLS supports client certificates, I've always wondered why browsers
never added UIs that would make that useable for end users.

~~~
n0w
It would be nice to have a JavaScript API that allows you to create a client
certificate locally, generate a CSR, and install the signed certificate for
automatic use when connecting back to the associated host?

------
farleykr
I'm a beginner in this area, but maybe someone can help me out. Would this be
a replacement for something like Passport or Auth0?

~~~
kroltan
Not exactly. It is an alternative to the concept of passwords in general. But
it is not a complete solution to all the things covered by those services.

------
tokenizerrr
Anyone know when the Google websites will start using this? Would love to
finally be able to use my Yubikey with Firefox and Google.

~~~
svacko
you can partialy (password + second factor authentication) use this when using
2FA with your Google account,
[https://support.yubico.com/support/solutions/articles/150000...](https://support.yubico.com/support/solutions/articles/15000006418-using-
your-yubikey-with-google)

~~~
tokenizerrr
Doesn't work with Firefox yet AFAIK. That page mentions requiring Google
Chrome.

~~~
tscs37
It works with Firefox 60, Google however sometimes relies on Chrome quirks not
specified in the standard which may not make it usable in Firefox. (Last I
checked)

~~~
tokenizerrr
It does not, and Google does not yet even attempt to use WebAuthn. They're
still using the (now legacy) U2F authentication mechanism, which firefox does
not fully support. It works in some sites if you enable it in about:config,
but not all. Like google.com.

~~~
tscs37
Hmm, yeah, I was more aiming at "Firefox has working WebAuthn in the newest
Version, Google just doesn't use it properly or at all", I should have
expressed that better.

------
krupan
How is this related to this:

[https://www.w3.org/TR/webauthn/](https://www.w3.org/TR/webauthn/)

?

EDIT: found this relevant comment (I think) from yesterday's discussion:
[https://news.ycombinator.com/item?id=17030302](https://news.ycombinator.com/item?id=17030302)

~~~
StavrosK
The first sentence in TFA:

> The Web Authentication API (also referred to as WebAuthn)

------
brianmcsweeney
Anyone have any idea if this work is aligning with the Decentralized
Identifier specification, or vise versa? [https://w3c-ccg.github.io/did-
spec/](https://w3c-ccg.github.io/did-spec/)

------
Roritharr
If Microsoft allows Windows Hello to be used by Firefox, Chrome etc to enable
this, this would be extremly huge. Same on mobile with Google & Apple.

Sadly i've got no idea how far away we are from this actually being
implemented.

------
miles_matthias
Looks great for web content, but how does it support the workflow of signing
up for a website on my browser and then downloading their mobile app, and
signing in on the app without a password?

Or is that TBD?

~~~
tialaramex
If your authenticator is suitable for your mobile device, then it works with
that device. If your authenticator is, say, a USB-A dongle for plugging into a
PC it probably either can't be used, or is super-clumsy because it needs a big
adaptor to hang off the device. They make things that do Bluetooth and USB-C
though.

~~~
miles_matthias
Gotcha. Although Apple and Google will likely need to build an API for this
like they did for facial/fingerprint unlock.

------
kennu
I wonder if you could use those keys also for encrypting content?

~~~
tialaramex
Not with this API. You can purchase objects which can do this AND handle say
your GPG keys for encryption, but WebAuthn is deliberately narrowly scoped.

Using the same key for unrelated things can result in unpleasant surprises. So
it's to be avoided.

If you have a crappy insecure email server that uses SSLv3 still, and uses the
same key as your tightly locked down Web server with TLS 1.2 then this bites
you really badly, I can use the email server to help me impersonate your web
server.

------
totony
I'd be curious to know why it chooses to have a register step, why not just
use the key of the authenticator/the relying ID as a proof of identity?

You would normally use a scheme like this so that websites cannot connect
multiple identities together, but it seems pointless here because the pubkey
will be signed with the user identity and the server will have logged your
real pubkey

~~~
emlun
No, you were right at the beginning. There is no "root" or "real" pubkey. A
separate keypair is generated each site, so that - like you said - identities
are unlinkable. This is also a crucial part of what makes these credentials
immune to phishing.

------
Edmond
I proposed something similar a few years ago, glad to see it being
incorporated into browsers:

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

------
xEnOnn
So the private key will be stored a device for signing in across a few
platforms. But what if I need to sign in from another device? I can't do that
until I go back home and copy the key over to my mobile?

------
agnivade
How costly are these devices ? Are these readily available in the market to
buy ?

~~~
emlun
Yubico currently sells one at $20. [https://www.yubico.com/product/security-
key-by-yubico/#secur...](https://www.yubico.com/product/security-key-by-
yubico/#security-key-2-pack)

There are competing U2F keys, but I don't know of any competitors that support
FIDO2 yet.

------
marknadal
Sigh, I got all excited, but then discovered this is to be used __with a
server __, which means it fundamentally propagates the idea of "fake security"
(where somebody else owns your identity, not you. Check out this explainer for
more info:
[https://gun.js.org/explainers/data/security.html](https://gun.js.org/explainers/data/security.html)
).

This is bad design philosophy, I instead encourage everybody to use the native
Web Crypto API to create accounts and do P2P E2EE encryption.

Web Auth API does look a lot easier than Web Crypto API, but it pushes the
wrong message. We've taken a lot of time to make an MIT/Zlib/Apache2 Open
Source wrapper around Web Crypto API that allows better user security (better
than Web Auth API), short tutorial here: [https://hackernoon.com/so-you-want-
to-build-a-p2p-twitter-wi...](https://hackernoon.com/so-you-want-to-build-
a-p2p-twitter-with-e2e-encryption-f90505b2ff8) .

~~~
supertrope
Unfortunately average people are better off with a corporation holding onto
their private keys. People already get annoyed when they forget their
password. Telling them they have permanently lost access to their account/data
because their hard disk broke or they lost their token is much worse.

