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

A Guide to WebAuthn

webauthn.guide

Post reply on HN
Print view View original

41–50 of 122 posts

Re: A Guide to WebAuthn

#41

Post by JshWright »

StavrosK wrote: post #24
ecesena wrote: post #21

I see a lot of comments of people interested to test it out. If you have a hardware token with NFC, you can now test it everywhere: Mac, Windows, Linux (), Android (all browser), iOS (Safari iOS 13.3+). This is a big achievement as less than 1y ago the story was sooo much different. If you do NOT have a hardware token, here are some options: - Windows with TPM or Hello - Mac with touchID sensor, you have to use Chrom…

Chrome beta on mobile didn't work for me with either fingerprint or any other method, the call to navigator.credentials.create just fails. Firefox half-works.

Firefox mobile works for me on https://webauthn.io

Which half doesn't work?

Re: A Guide to WebAuthn

#42

Post by combatentropy »

StavrosK wrote: post #31
akubera wrote: post #29

So this is like BrowserID/Persona but instead of including the third-party email service to prove identification, the only credentials are on device/in-browser, right? I assume that if you only connect one computer (authenticator) and lose the device, you're either SOL or the service has some workaround where you pre-register an email address or a separate "Login With" service.

No, it's a new standard where the site securely negotiates the login with the browser. What happens after that is the browser's job, all the site cares about is that it sees a correct credential. Eg your password manager could implement this so all you'd have to do is click "log in" and you'd be in, without usernames or passwords to remember or steal.

So, how do you keep someone else from sitting down at your computer and clicking Log In? Am I right in guessing that fundamentally you're back to passwords, in the sense that when you are away you lock your computer screen and have to enter a password to unlock it (or some other implementation that still relies on passwords, like if your browser requires a master password to use its password manager, etc.)

Re: A Guide to WebAuthn

#43

Post by nickray »

zaroth wrote: post #37
Rafert wrote: post #28

Earlier quoted context omitted.

Yes, that's what is recommended and most sites implement (AFAIK Twitter for some reason only permitting one :-/)

And how do you enroll the second device? It would have to be something like; 1) Login on primary device 2) Generate a one-time code or link 3) Enter one-time code or click link on 2nd device 4) Click an “Enroll” button on the 2nd device which would generate a second enrollment saved in the account. You would have to do this for each and every service so that seems like a total non-starter. Alternatively, a way to sha…

There's an ascending signature counter that's intended to prevent cloned devices (replay attacks are prevented seperately with server generated challenge). One way around it is clone (backup key) having very high initial signature counter set, so first use invalidates original (on loss). But yeah it's a UX problem that hopefully will find a better/non-hacky solution than "register multiple keys for each site".

Re: A Guide to WebAuthn

#44

Post by combatentropy »

This guide focuses on what WebAuthn looks like for the server. What does it look like for the user?

As far as I can imagine, it boils down to relying on the possession of a certain piece of hardware instead of knowing a certain password. That is, I have to carry around some kind of USB device and plug it into every computer I want to use. The device holds all my secret keys and does all the magic behind the scenes. But if I lose my device, then I can't log in. And if someone steals my device, then they can log in.

Maybe you can make it more convenient by using my phone instead of a specialized USB device, since everybody is always carrying around their phone everywhere they go anyway, right? But I just want to know that I understand the entire landscape first, from the point of view of the user, at a broad level. What are the user's options? What exactly does the user do? Is this only for smart users? If I made a web app for the general public, and my only method of authentication was WebAuthn, would the average user easily figure out what to do, or would they give up and walk away?

Some have mentioned "software-based" tokens, but then how are those kept safe? With a master password? Then we're back to passwords.

Re: A Guide to WebAuthn

#45

Post by sam_lowry_ »

StavrosK wrote: post #33
sam_lowry_ wrote: post #27

Earlier quoted context omitted.

There is no way to generate your own software key pair as easily as one can do with ssh-keygen. The whole spec is designed with hardware tokens in mind, software tokens are not mentioned anywhere, and WebAuthn spec designers wave their hands when asked about software tokens.

You can just implement the client in software and use it if you want, the protocol doesn't care. Firefox already ships with that functionality and you can enable it.

>Firefox already ships with that functionality >and you can enable it.

I can't find anything like that, can you point us to the docs/examples?

OTOH, I see that someone right now posted a reply to https://github.com/w3c/webauthn/issues/1175#issuecomment-570... trying to downplay the issue of purely software tokens

Funnily, https://github.com/herrjemand/awesome-webauthn#software-auth... is not about software tokens but about webauthning with an Android phone or a Wear OS.

Re: A Guide to WebAuthn

#46

Post by stavros »

combatentropy wrote: post #42
StavrosK wrote: post #31

Earlier quoted context omitted.

No, it's a new standard where the site securely negotiates the login with the browser. What happens after that is the browser's job, all the site cares about is that it sees a correct credential. Eg your password manager could implement this so all you'd have to do is click "log in" and you'd be in, without usernames or passwords to remember or steal.

So, how do you keep someone else from sitting down at your computer and clicking Log In? Am I right in guessing that fundamentally you're back to passwords, in the sense that when you are away you lock your computer screen and have to enter a password to unlock it (or some other implementation that still relies on passwords, like if your browser requires a master password to use its password manager, etc.)

You use some method of authentication, of course. How do you keep someone who has your unlocked password manager from using it? You just make sure nobody is ever in that situation.

The big win is that, with WebAuthn, you don't need to also hide your authentication from site operators, your OS, key loggers, phishers, etc etc.

Re: A Guide to WebAuthn

#47

Post by nickray »

sam_lowry_ wrote: post #26
arianvanp wrote: post #8

Earlier quoted context omitted.

There are already open source hardware and software available by the people at SoloKey. Both Nitrokey and SoloKey sell the tokens.

Sell? Bingo! That's what I was talking about.

SoloKeys person here ;) You can implement software authenticators (listening on local USB port), I imagine some password manager people will do so eventually, or have a direct way to hook into requests. Krypton did this for U2F.

Hardware keys are for if you want hardware security, obviously they can't be free unless you want someone with a different business model to subsidise them.

Re: A Guide to WebAuthn

#48

Post by StavrosK »

JshWright wrote: post #41
StavrosK wrote: post #24

Earlier quoted context omitted.

Chrome beta on mobile didn't work for me with either fingerprint or any other method, the call to navigator.credentials.create just fails. Firefox half-works.

Firefox mobile works for me on https://webauthn.io Which half doesn't work?

For me, authentication, though I see it works on that site. Maybe I made a mistake somewhere.

Re: A Guide to WebAuthn

#49

Post by StavrosK »

sam_lowry_ wrote: post #45
StavrosK wrote: post #33

Earlier quoted context omitted.

You can just implement the client in software and use it if you want, the protocol doesn't care. Firefox already ships with that functionality and you can enable it.

>Firefox already ships with that functionality >and you can enable it. I can't find anything like that, can you point us to the docs/examples? OTOH, I see that someone right now posted a reply to https://github.com/w3c/webauthn/issues/1175#issuecomment-570... trying to downplay the issue of purely software tokens Funnily, https://github.com/herrjemand/awesome-webauthn#software-auth... is not about software tokens but…

Here:

https://news.ycombinator.com/item?id=21963399

Which comment is trying to downplay the issue? What is the issue?

Re: A Guide to WebAuthn

#50

Post by combatentropy »

stavros wrote: post #46
combatentropy wrote: post #42

Earlier quoted context omitted.

So, how do you keep someone else from sitting down at your computer and clicking Log In? Am I right in guessing that fundamentally you're back to passwords, in the sense that when you are away you lock your computer screen and have to enter a password to unlock it (or some other implementation that still relies on passwords, like if your browser requires a master password to use its password manager, etc.)

You use some method of authentication, of course. How do you keep someone who has your unlocked password manager from using it? You just make sure nobody is ever in that situation. The big win is that, with WebAuthn, you don't need to also hide your authentication from site operators, your OS, key loggers, phishers, etc etc.

Thanks. Like you said, this is safer, even if a password remains somewhere in the chain, like a master password for your computer. An advantage is that websites are not storing passwords (hashed or otherwise, because it's hard to do well).
Post reply on HN