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

Yubico and Microsoft Introduce Passwordless Login

yubico.com

Post reply on HN
Print view View original

201–210 of 218 posts

Re: Yubico and Microsoft Introduce Passwordless Login

#201

Post by airstrike »

rando444 wrote: post #169
airstrike wrote: post #115

Earlier quoted context omitted.

> Friends and family can also steal your credit card, but this is not where the majority of credit card theft comes from. This is a false equivalence because knowing someone's credit card data only allows you to do one thing which happens to be pretty detectable: using their credit card for yourself. Knowing someone's password allows you to know one or more of their secrets, including many applications that are virtu…

You're making the false equivalence. There's no reason that using a password/key can't be just as detectable as using a credit card. Also trying to trace logins application side is rather foolish IMHO, this should always be done at the authority that is granting the authorization.

> There's no reason that using a password/key can't be just as detectable as using a credit card.

That's not my point. The status quo is that people get alerted if something uses their credit card inadvertently and don't have similar alerts for uses of their password other than in a handful of situations like Gmail logins.

It's definitely not impossible for people to keep tabs on their logins, but this isn't how the Average Joe operates.

Re: Yubico and Microsoft Introduce Passwordless Login

#202

Post by rando444 »

airstrike wrote: post #201
rando444 wrote: post #169

Earlier quoted context omitted.

You're making the false equivalence. There's no reason that using a password/key can't be just as detectable as using a credit card. Also trying to trace logins application side is rather foolish IMHO, this should always be done at the authority that is granting the authorization.

> There's no reason that using a password/key can't be just as detectable as using a credit card. That's not my point. The status quo is that people get alerted if something uses their credit card inadvertently and don't have similar alerts for uses of their password other than in a handful of situations like Gmail logins. It's definitely not impossible for people to keep tabs on their logins, but this isn't how the…

Switching to a hardware based login system and getting centralized alerts when that login is used is likely going to be the default, not some pipe dream.

Plus, there's also the obvious solution for potentially stolen and misused keys .. just add a PIN.

Re: Yubico and Microsoft Introduce Passwordless Login

#203

Post by emlun »

StavrosK wrote: post #182
emlun wrote: post #170

Earlier quoted context omitted.

We have C, Python and Java libraries released right now, all of which are beta WIP as we don't yet have any users who can inform the API designs from real world use cases. https://github.com/Yubico/libfido2 https://github.com/Yubico/python-fido2/ https://github.com/Yubico/java-webauthn-server

I'm thinking of writing a Django-webauthn library (although I'm not sure if it would just be simpler to fork django-u2f). Would the Python library help at all? It looks like it's for USB communication and not for general helpers around signing/authentication/etc.

It's mostly for host-authenticator communications, yes, but it it includes a couple of helpers for verifying signatures. But you're right it's not a full-featured server library at this point.

Re: Yubico and Microsoft Introduce Passwordless Login

#205

Post by emlun »

not_that_noob wrote: post #186
StavrosK wrote: post #183

Earlier quoted context omitted.

It's not, you're misunderstanding and spreading misinformation. The "key to the kingdom" is a random asymmetric keypair. The PIN is only there as a second factor to this key to prevent physically stolen keys being used to authenticate. If you enter the PIN wrong five times, the device can just lock itself. There might be a way to steal the PIN if the user enters it on a compromised machine, but you can't do anything…

I think you misunderstand how the CTAP portion of Webauthn works - once the root credential authenticates the user, they no longer have to use passwords for the user’s various accounts. The simple point is that if this credential became compromised for whatever reason, then all associated accounts are by definition compromised.

Wait a second. Web Authentication is not an SSO framework - there's no "root credential". Each server you use the token on gets its own keypair which is used for only that site.

It seems like the scenario you're describing in further replies is this: 1) Alice has an account at service A and an account at service B, and authenticates to both with the same FIDO2 token. 2) Eve calls service A and convinces them she's Alice and needs a new token. 3) Service A sends Eve a new token registered to Alice's account. 4) Eve uses the new token to log in as Alice at service B.

The above attack is not possible, since the keypair for service A is not usable at service B. This separation of credentials for separate services is a fundamental FIDO/WebAuthn design feature for damage control and user privacy. Eve can use the new token to log in to service A, yes, but only to service A.

Even if service A and service B were to try to cooperate out-of-band to support each other's credentials, the browser would not let them unless they're on the same domain.

Re: Yubico and Microsoft Introduce Passwordless Login

#206

Post by emlun »

not_that_noob wrote: post #188
StavrosK wrote: post #187

Earlier quoted context omitted.

Yes, certainly. And in order to compromise that root credential, you'd have to physically steal the key, and either decap the chip and read the bits somehow, or find a vulnerability that allowed you to read the private keys through USB. Needless to say, this is much, much harder than stealing someone's password.

Credential reissue (lost token) would be a much easier path for an attacker. The weakest point is always the point of compromise. For the smart attacker therefore, they have been handed the whole set of accounts. So yes the original point stands - attackers will find it more lucrative to do account compromise in the Webauthn world.

I think you misunderstand how WebAuthn works - see my other reply to your previous message.

Re: Yubico and Microsoft Introduce Passwordless Login

#207

Post by emlun »

not_that_noob wrote: post #162
zaarn wrote: post #156

Earlier quoted context omitted.

I don't see that as a flaw really. It's not different to having a password manager, with proper WebAuthn atleast. What you do is you take this key that unlocks the kingdom. And then you keep it safe. Unlike before there isn't 20 keys that unlock parts of the kingdom that might lead to unlocking other kingdoms via roundabout ways. Your attention for security can be focused on a single key. The average users will be mu…

The flaw stems from the fact that an attacker can thru social engineeung acquire that root crendential (password or biometric or token). Once they have it, they can clean out all your banking, stock and home equity line accounts in one sweep. You as a user may not know that credential is compromised - maybe it was a key logger, maybe it was social engineering the cell phone provider to port your number and then quali…

I think you misunderstand how WebAuthn works - there's no "root credential". See my other reply https://news.ycombinator.com/item?id=17032637

No third party issues tokens in WebAuthn either - you have your one or a couple of authenticators you use everywhere, and those authenticators create their credential keypairs locally on the device (and a separate keypair is created for each site - they're not shared between sites).

Re: Yubico and Microsoft Introduce Passwordless Login

#208

Post by emlun »

emlun wrote: post #174
datalog19908 wrote: post #149

Earlier quoted context omitted.

> he new YubiKeys support an on-device PIN that isn't shared with the server Doesn't this PIN become a master password for all the websites at that point?

In a sense, yes, but the keyword is "on-device". It's not shared with the server, so it can't be remotely intercepted - but it _can_ be changed in a single place (the YubiKey) should it ever be compromised.

Oh, maybe I didn't get the entire question. There's no global identity or "root credential" used for all websites. A separate keypair is created for each website, and a keypair for site A is not usable on site B even if site B somehow has the public key.

Re: Yubico and Microsoft Introduce Passwordless Login

#209

Post by emlun »

not_that_noob wrote: post #151
datalog19908 wrote: post #149

Earlier quoted context omitted.

> he new YubiKeys support an on-device PIN that isn't shared with the server Doesn't this PIN become a master password for all the websites at that point?

That’s really the flaw of single sign-on and Webauthn - that one key now unlocks the kingdom.

To be more precise, the PIN is the key that unlocks the keyring (the hardware token) that contains the keys (asymmetic keypairs) to the various kingdoms (websites). WebAuthn is not a single sign-on framework, and there's no "root credential" that's used everywhere.

Re: Yubico and Microsoft Introduce Passwordless Login

#210

Post by emlun »

not_that_noob wrote: post #190
Freak_NL wrote: post #164

Earlier quoted context omitted.

Whether you use a hardware key, or a password manager, in both cases the attacker needs both authentication factors: your password, and the hardware key or password manager. With a hardware key you gain the advantage of the attackers having to physically gain access to that key.

This is the misunderstanding attackers can exploit. Credentials need to be reissued because people lose them ocassionally. So that process now becomes a pathway for exploits.

No - that process _remains_ a pathway for exploits against the particular website being targeted. The process does not open new pathways for transferring exploits from one site to another - on the contrary, such exploits are made more difficult by the separation of credentials.
Post reply on HN