4 ms·

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

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.

sabrehagen 5y ago
You referred to 'QR + CV + HTTPS system'. Is there more to the CV component than taking a photo?
- thekeyper 5y ago
  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.
tialaramex 5y ago
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.
- thekeyper 5y ago
  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.
  - qzw 5y ago
    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?
    - thekeyper 5y ago
      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.
  - deleted 5y ago
    [deleted]
- ignoramous 5y ago
  > 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.

sabrehagen 5y ago

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

thekeyper 5y ago
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.

tialaramex 5y ago

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.

thekeyper 5y ago
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.
- qzw 5y ago
  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?
  - thekeyper 5y ago
    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.
- deleted 5y ago
  [deleted]
ignoramous 5y ago
> 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.