Live data from Hacker News

Web Authentication API

developer.mozilla.org

31–40 of 76 posts

Re: Web Authentication API

#31
post #20
post #10

Earlier quoted context omitted.

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.

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

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.

Re: Web Authentication API

#32
post #20
post #10

Earlier quoted context omitted.

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.

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

This could introduce latency and centralization to the authentication process, but perhaps there could be a public key server/service that would allow the user to issue a revocation certificate.

This scenario could also be a legitimate use case for blockchain technology.

Re: Web Authentication API

#33
post #26

Earlier quoted context omitted.

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)

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.

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.

Re: Web Authentication API

#36
post #5
post #4

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

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.

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

Re: Web Authentication API

#37

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?

If the key is designed properly, no. For example, Yubikey does not store any state:

https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/

Re: Web Authentication API

#38
post #20

Earlier quoted context omitted.

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

This could introduce latency and centralization to the authentication process, but perhaps there could be a public key server/service that would allow the user to issue a revocation certificate. This scenario could also be a legitimate use case for blockchain technology.

If there isn't a solution in place for revocation, then it's not really an authentication solution, IMO. I would have thought this would be part of the proposed API. Do you think it belongs there?

Re: Web Authentication API

#39
post #38

Earlier quoted context omitted.

This could introduce latency and centralization to the authentication process, but perhaps there could be a public key server/service that would allow the user to issue a revocation certificate. This scenario could also be a legitimate use case for blockchain technology.

If there isn't a solution in place for revocation, then it's not really an authentication solution, IMO. I would have thought this would be part of the proposed API. Do you think it belongs there?

This functionality is orthogonal to the API.

If say my Gmail is configured to trust my awesome Darth Vader bobble head authenticator, the tiny one I keep on my keychain and one that's in my locked desk drawer with my cyanide pills and then I lose my keys somehow, I go home, use the Darth Vader to sign in, click for the account credentials page, pick the keychain one and pick remove. I can add another one when I buy it, using the ordinary enrollment step.

No new API needed or desired.

The trick to U2F and this whole family of technologies is that the devices are really dumb, your authenticator doesn't remember "I'm allowed to authenticate to Google, I picked this key" it just turns google.com into a number and uses that with some crypto arithmetic. If you never actually enrolled with Google, the results are worthless but it has no idea. If I try to sign into Mike's account with Sarah's authenticator, it doesn't work but there's no clue why. The authenticator doesn't even know it's Sarah's.

Post reply on HN