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

61–70 of 122 posts

Re: A Guide to WebAuthn

#61

Post by nickray »

sam_lowry_ wrote: post #52
nickray wrote: post #47

Earlier quoted context omitted.

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.

Listening to local USB port? Hm... Why should I listen to a local USB port to exchange keys in a PKI? This only proves my point that WebAuthn is about hardware replacing passwords.

Yes, WebAuthn is about getting rid of passwords. They're a bad idea, for most people, in most situations.

Re: A Guide to WebAuthn

#62

Post by tialaramex »

combatentropy wrote: post #44

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

The most common use case today is 2FA, where WebAuthn is the standard way to do something U2F defined only for 2FA.

In this scenario where it's only a second factor, yes, it relies on you possessing a Security Key, and on the bad guys not possessing it. This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.

WebAuthn (and U2F) were specifically designed to register multiple tokens, the server-side stuff described explains how a site insists "Look I need to register a new token, not these tokens which I already registered" while also being open to whichever token you have on login, "Any of these tokens can log in, I don't mind which". So I have a token in my pocket, but if I got mugged I have a backup token at home that can substitute. Well designed sites let you nickname them during registration so you can go "I lost green hulk token but I still have Yubikey" later.

Yes, if you use the flows where both factors are handled by the FIDO token then you're "back to passwords" but with a very important difference. Very, very important:

Right now your password for news.ycombinator.com is known by the Y Combinator servers. Now, I'm sure they take good care of it, using a modern salted and pessimised hash for the purpose, but this creates many extra opportunities for vulnerabilities and a bad guy only needs to find a crack in one place.

Whereas if I have a PIN for my FIDO token the PIN lives on the FIDO token. Not on every web site I use WebAuthn with, not in a database that some poor new sysadmin accidentally uploads to the Cloud, it's not sent over the wire to some Java backend sevice that might accidentally log it, or whatever. The device can insist upon rate-limiting attempts because it's a piece of hardware, like an iPhone.

Re: A Guide to WebAuthn

#63

Post by nickray »

sam_lowry_ wrote: post #58
sam_lowry_ wrote: post #45

Earlier quoted context omitted.

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

@nickray, with ssh, I manage the root of thrust. With Webauthn, someone else manages it for me, be it Yubico or Intel or Apple. This is a fundamental difference.

As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc.

I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qualified for.

This is what I meant by "safe defaults". Yes some people use e.g. password managers, but no, most people don't. Yes, some people manage to use GPG to manage their ssh keys, but no most people, even qualified, don't/can't/won't.

"Bad defaults with patches hopefully making it safe" is just not the way we should be heading.

Re: A Guide to WebAuthn

#64

Post by tialaramex »

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…

Ah, I see you're thinking about platform devices where the web browser is running on the device being enrolled.

Yes, you'd have to use some other way to authenticate as yourself on a second or subsequent platform device. If you have a separate FIDO token (like a Yubikey or any of their cheaper Security Key products or dozens of others) that would be the obvious first choice to enroll.

Re: A Guide to WebAuthn

#66

Post by Rafert »

sam_lowry_ wrote: post #51
Rafert wrote: post #32

Earlier quoted context omitted.

> They are stored on hardware tokens. Not necessarily: the WebAuthn spec mentions two other types of authenticators in the introduction section ( https://www.w3.org/TR/webauthn-1/#intro ): "Broadly, compliant authenticators protect public key credentials, and interact with user agents to implement the Web Authentication API. Implementing compliant authenticators is possible in software executing (a) on a general-purp…

The section https://github.com/herrjemand/awesome-webauthn#software-auth... talks about using Android phones or Wear OS to webauthn with Bluetooth. The section title is misleading. It's not about software tokens, but about turning one's phone or a smart watch into a hardware token.

The section title is correct: they're authenticators implemented in software, not relying on a TEE/TPM or any other bit of hardware for storing the keys. Apparently these don't run on on your CPU architecture and/or operating system of choice, but that's another issue. The claim of "they are stored on hardware tokens, there does not seem to be a way to have privately generated software keys" is incorrect.

Perhaps https://github.com/bodik/soft-webauthn is closer to what you're looking for.

Re: A Guide to WebAuthn

#67

Post by combatentropy »

tialaramex wrote: post #62
combatentropy wrote: post #44

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

The most common use case today is 2FA, where WebAuthn is the standard way to do something U2F defined only for 2FA. In this scenario where it's only a second factor, yes, it relies on you possessing a Security Key, and on the bad guys not possessing it. This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you. WebAuthn (a…

> This matches the threat model, which is typically that bad guys are not your flatmate or your mother they live in another country and will never meet you.

Yes, that's a good point. No security is foolproof. But this is an easy way to curb 99%

> "back to passwords" but with a very important difference

Also a great point. It may not totally get rid of passwords, but it does stop leaks.

Re: A Guide to WebAuthn

#69

Post by sam_lowry_ »

nickray wrote: post #63
sam_lowry_ wrote: post #58

Earlier quoted context omitted.

@nickray, with ssh, I manage the root of thrust. With Webauthn, someone else manages it for me, be it Yubico or Intel or Apple. This is a fundamental difference.

As Stavros mentions, you can, and if you feel qualified, you should manage your own keys. Be that with some software authenticator you deem safe or write yourself, or with e.g. our keys that are open source, so you can modify anything to your liking, etc. etc. I sense a bit of 90s security thinking from your arguments though, where every end user and mid-level admin handles security decisions they're frankly not qual…

>every end user and mid-level admin handles >security decisions they're frankly not >qualified for.

It's better for the society to let them make their share of mistakes. In the longer term, everyone will be safer and, incidentially, more intelligent.

Re: A Guide to WebAuthn

#70

Post by cbsmith »

combatentropy wrote: post #44

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

You can make it more convenient by having a specialized USB or NFC device. The NFC handshake is really simple (tap your phone with it). Arguably more convenient than any kind of secure software-based tokens.
Post reply on HN