Live data from Hacker News

Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

news.ycombinator.com

51–60 of 98 posts

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#51

Earlier quoted context omitted.

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…

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

> 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

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#52
post #47

I'm having trouble with the demo... registration and login flows both end in a screen that says "Select a Kyri service Manager account to login" but has no list of accounts. Email in profile if you don't want to troubleshoot this publicly.

Sent you an email. Anyone else - please let me know if you're having trouble with the demo here or email me - zain@keyri.co

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#54
post #48

What’s the process for when a user gets a new phone? I dread getting one because my keys depending on the phone completely disappear and have no transfer mechanism.

Two options, each configurable by the developer implementing the SDK:

(1) When a user sets up their new phone using an iCloud / Google Drive backup of their old phone, the private keys will be already embedded in the relevant apps when they first open the app on the new phone. The developer can ask the user to decrypt the private key for the first session with a user-defined passcode

(2) The SDK provides a QR backup system - users can export their private key in a QR code, print it out or save it on a USB drive, and then scan that code using their new phone. Alternatively, they can just open that QR backup screen on their old phone and scan that with the same app on their new phone. Google Authenticator recently released a key export feature like this (we had it before Google, but it's inspired by blockchain.com's wallet backup system from 2012).

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#55
post #45

Earlier quoted context omitted.

Regarding your first point: phones are already intrinsic to authentication, whether it's through SMS OTP, TOTP, or push notification verification. Wherever you have 2FA enabled (other than email magic link), you are generally SOL if you lose your phone. We are well past the days when people would forget their phone at home, and most people have their phones within reach. That said, our early customers are looking to…

Account sharing is never unethical. It's my account and I'll damn well give access to whoever I please. Services such as Netflix mitigate this by limiting the amount of concurrent use, which is fine.

That's a fair point for services that limit use based on number of concurrent devices/streams. There are, however, many services that explicitly state the account may only be used by a given single user and those providers will seek legal action if that user shares their account. This ultimately leads to significant pain for both the company and user.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#56

Looks intriguing, but do I have to take a picture every time I log in? That seems inconvenient. I'm having trouble understanding what more this offers over a model more like TOTP/HOTP, where I can scan a QR code once from a site, then log in with it even if my phone doesn't have connectivity (which is a more common use case than you might think). If I do have connectivity, why not just throw a prompt up on my phone a…

Login on desktop happens through scanning a QR code on the service's login page using the service's app. On a mobile device, logging in happens by tapping a button and being verified by biometrics (FaceID etc.) or a passcode (if enabled by the developer).

TOTP is an objectively worse UX - first you type in your username, then password, then open your phone, open the relevant app, read the code, and type in the code before it expires. With Keyri, you open the relevant app, tap a "scan" UI element, and point it at your screen. No typing, memorization, or race against the clock. Also, with TOTP, you're pulling out your phone and navigating to a specific app anyway, so I don't understand your UX objection. I'm also struggling to picture a situation in which a laptop or other device has connectivity but a phone does not. Presumably the laptop is on a WiFi network that the phone can also connect to. If the laptop is using some sort of satellite connection module, that module and/or laptop can fire up a hotspot. This connectivity problem would also arise in the push notification solution you propose in the next sentence.

Push notification solutions ("prompts") are defeatable using trivial man-in-the-middle phishing techniques. For example: https://github.com/kgretzky/evilginx2. Authenticator-initiated authentication solutions with two-way authentication like Keyri eliminate phishing.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#58

Does this use hyperledger aries? https://www.hyperledger.org/use/aries

We do not use Hyperledger Aries, but thanks for showing us. I have a blockchain background, and Keyri is somewhat inspired by blockchain concepts, but we've stayed away from blockchain-based solutions for privacy reasons. The pseudonymity of traceable blockchain transactions (in the auth scenario, authentication request transmissions) do not provide adequate privacy. Apologies if I'm misinterpreting Aries - perhaps its ledger is not publicly viewable. I have other objections to blockchain-based identity solutions, but privacy is the main one.

Then there are other passwordless auth solutions employing "private blockchains". That term basically means "database" in my mind and is obviously not ideal from a privacy perspective.

Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication

#60

CyberArk already does this... it's called Vendor Privileged Access.

The similarities with VPA/Alero end at the concept of QR-based login. It is a system for provisioning enterprise vendors and requires a substantial onboarding process. It is not an SDK for integration into consumer-facing / third-party applications.

Can't speak for how it works on the back end (though it clearly works differently from Keyri given VPA's QR code contains much more data and is therefore slower / more unreliable to scan). In terms of security on the front end, VPA is phishable as explained in earlier comment threads.

Post reply on HN