Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Authentication API

developer.mozilla.org

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Web Authentication API

#51

Post by miles_matthias »

tialaramex wrote: post #41
miles_matthias wrote: post #40

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?

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.

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

Re: Web Authentication API

#52

Post by cornholio »

icebraining wrote: post #47
cornholio wrote: post #44

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…

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.

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.

Re: Web Authentication API

#53

Post by tialaramex »

darkhorn wrote: post #34

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?

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.

Re: Web Authentication API

#54

Post by 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

Re: Web Authentication API

#55

Post by homakov »

cornholio wrote: post #44

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…

You just described https://github.com/sakurity/securelogin

Re: Web Authentication API

#56

Post by [deleted] »

totony wrote: post #54

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

[deleted]

Re: Web Authentication API

#57

Post by n0w »

danellis wrote: post #50

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

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?

Re: Web Authentication API

#58

Post by emlun »

jsgo wrote: post #45
tptacek wrote: post #4

For people confused about what this is: it's basically the de facto cross-browser standard for U2F security keys like Yubikeys.

So I like this concept based off what I can see (basically like a RSA or similar w/o the generated token, or rather having to enter said token manually). Question: Microsoft was pushing hard that they're going towards passwordless, and if memory serves, it was through the FIDO Alliance stuff. So how do we get there with this? I'm assuming this is supplemental to that (a "second factor"), but what else gets us there?

Web Authentication is part of FIDO2, which is what Microsoft is pushing. Whether you use it for passwordless login or second factor depends on what the server wants and what authenticator hardware the user has.

Re: Web Authentication API

#59

Post by emlun »

tscs37 wrote: post #25
euroclydon wrote: post #11

Earlier quoted context omitted.

Is this like Client Certs without the connection to the SSL cert? Oh, I guess client certs are owned and controlled by the server owner...

Sorta, Client Certs but the Client generates and authenticates them, the Server only stores the fingerprint and authenticates them on it's side. And with a better UI and flow since you don't need it to establish connection.

Yeah, and a separate keypair is generated for each site.

Re: Web Authentication API

#60

Post by emlun »

totony wrote: post #54

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

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.
Post reply on HN