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

41–50 of 76 posts

Re: Web Authentication API

#41

Post by tialaramex »

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.

Re: Web Authentication API

#42

Post by ajross »

dmortin wrote: post #6
Ajedi32 wrote: post #3

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.

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.

It's not a substitute for 2FA, just one of the factors. You will still need a password to authenticate new devices, etc...

Re: Web Authentication API

#43

Post by tialaramex »

StavrosK wrote: post #31
dmortin wrote: 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?

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.

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.

Re: Web Authentication API

#44

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

Re: Web Authentication API

#45

Post by jsgo »

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?

Re: Web Authentication API

#46

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

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

Re: Web Authentication API

#47

Post by icebraining »

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.

Re: Web Authentication API

#49

Post by supertrope »

marknadal wrote: post #46

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 ). This is bad design philosophy, I instead encourage everybody to use the native Web Crypto API to create accounts and do P2P E2EE e…

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