Hacker News Reader

Comment by tialaramex | Hacker News Reader

For the smartphone case, why would I want to pay for Keyri, rather than use WebAuthn (for the web) or the smartphone OS-provided FIDO2 feature that ships with the OS?

https://developers.google.com/identity/fido/android/native-a...

View on HN

WebAuthn has the added benefits of not being tied to any single vendor, and on the desktop you can use it with a hardware security key instead of a smartphone (people without smartphones who use services on the web exist you know). On a smartphone it just uses the Trusted Platform Module as its key store.

Agreed that WebAuthn is valuable in mobile-only cases, but I don't think it can transition to desktop web for a large majority of people. The overlap in a Venn diagram of "people who use hardware security keys" and "people without smartphones" just seems vanishingly small. BTW, Keyri also uses the TPM / secure enclave as its key store.

So how do you support people without smartphones?

Our system does not support people without smartphones, which is why we are addressing companies that are mobile-first or generally have more tech-forward userbases with ~100% smartphone adoption. For mobile-first platforms in particular, our system helps them flesh out a "WhatsApp-like" auth UX, which is industry leading in our opinion, without a long development cycle.

That's kind of limiting and exclusive. It sounds great for the next Clubhouse or Yo, but it seems like a dead end for anything serious like banking or any service that takes inclusion and disabilities serious.

Keyri makes less sense for smartphone-only applications. The primary case we solve for is applications that have both mobile and desktop web interfaces. Phones are already essentially considered trusted devices, whether auth there happened via password, SMS OTP, OpenID, FIDO2, etc. Keyri bridges the "trust gap" between the trusted smartphone in the user's hand and the untrusted desktop computer / smart TV / whatever other screen they're sitting in front of via our QR + CV + HTTPS system.

Deploying WebAuthn / FIDO2 on desktop web/native apps is far more challenging given the standard's need for communication between the authenticator device and client device to happen via USB, Bluetooth, or NFC. USB is obviously out of the question for consumer-facing apps, and companies simply can't ask typical users to connect their devices via Bluetooth - setup and reliability are the UX issues with BT.

For the desktop scenario, the reason that "trust gap" exists is that the chain of custody is too murky and if Keyri solves that I didn't see how. Of course maybe that's your secret sauce.

Specifically, how does the phone know which web page its owner is looking at on their laptop when they scanned the QR code ? You need to arrange that it's not possible to take the QR code generated for you and present it to a sucker for them to scan instead so that you're signed in as them and like I said, if Keyri does that then I don't see how.

> Specifically, how does the phone know which web page its owner is looking at on their laptop when they scanned the QR code? You need to arrange that it's not possible to take the QR code generated for you and present it to a sucker for them to scan instead so that you're signed in as them...

Isn't this a problem then with WhatsApp Web login too which shows a QR code (presumably not tied to any one account as the web-client seemingly generates it without any user-input) that the app then scans to initiate auth?

I was also wondering if its a severe vulnerability, given that the phone (roaming authenticator) continues to be in the possession of the victim, and they retain the ability to revoke other keys / tokens (which could additionally be authz restricted) shared with untrusted devices (client/platform), much like how one would revoke leaked API keys?

Btw, am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence? Thx.

> am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence?

FIDO2 isn't interested in this problem at all. From the point of view of FIDO2 the rpId ("Relying Party ID" the thing that distinguishes Apple from Facebook) is just arbitrary data selected by the application.

WebAuthn solves the problem by trusting the web browser to know which web site you're visiting. Specifically, the relying party (a web site you're trying to sign into) gets to pick a DNS name you'll authenticate against but the browser matches this DNS name against the HTTPS URL you're looking at, and rejects requests that don't match. The rpId is based on this DNS name, so a phishing site can't work.

e.g. You may think this page is from your bank, but your browser knows it's https://fake-bank.example/ and won't give it WebAuthn credentials for real-bank.example even though you firmly believe that's where you are.

> Isn't this a problem then with WhatsApp Web login too

Yes, it's an issue with WhatsApp QR login and every other QR login implementation.

> I was also wondering if its a severe vulnerability

It can be severe if the attacker only needs to be authenticated in the victim's account for a short while to do damage. For example, to withdraw cryptocurrency from an exchange account. Or, in the case of WhatsApp, to extract damaging personal info. Persistent access is not a prerequisite for the ability to do harm.

> Am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 by relying on BLE, USB, NFC to prove user-presence

Partially correct - there's two-way communication in FIDO2/CTAP2 in which the roaming authenticator confirms the "identity" of the web session before sending an auth request. The user-presence aspect is incidental to these three protocols. We do the same thing, just with CV

Nail on the head. That's the problem that the secret sauce solves. Without going too much in to it (because I don't think it's a very defensible moat at the moment), the phone sees stuff on the screen other than the QR code, which bad actors cannot present to victims.

So are you saying that even if the bad actors found out how the secret sauce works, they would not be able to spoof a legit page? In other words, is the obscurity in the CV part purely for competitive reasons, or does it also serve a security purpose?

Yes, even if bad actors figured out the secret sauce, they couldn't defeat it easily. It's possible, but if they hack you the way they'd have to hack you in order to defeat our CV element, you'd have much bigger problems to worry about. So yes, the lack of disclosure is for competitive reasons, not for security purposes.

You referred to 'QR + CV + HTTPS system'. Is there more to the CV component than taking a photo?

Yes, there's more to it than just reading the QR code. As mentioned above, I don't think it's a very defensible tech differentiator right now (lots of better-funded cybersecurity companies out there), but in summary, the phone sees stuff on the screen other than the QR code.

Reply on news.ycombinator.com