Live data from Hacker News

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

news.ycombinator.com

41–50 of 98 posts

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

#41

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…

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.

[deleted]

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

#42
post #40

Earlier quoted context omitted.

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.

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

#43
post #35

I was immediately intrigued by the proposal, though I can't imagine ever wanting to rely on my phone to be identified (what if my battery dies? I left it in another room? hey, a customer is gone and that sale has not gone through). > They also allow users to share their subscription accounts with others, robbing companies of revenue. This made me question your motives: "robbing" is a very strong statement for somethi…

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 deploy Keyri as an option parallel to password-based auth, which, while not ideal, is a smooth way to transition their users to a better UX that just happens to be more secure.

Regarding account sharing: agreed that the "robbing" language is harsh and should be toned down. That said, it is a problem that deserves a solution. For example, there are companies like data providers that charge businesses hundreds or thousands per month for access to their platforms, and they face massive account sharing issues from these businesses that can totally afford to pay for all of the seats they need but are not willing to pay because they don't need to - they can just share accounts among their employees. At the same time, I'd argue that any account sharing, even if it's for a $5/month streaming platform account, is unethical and a violation of TOS - companies should have access to tools that definitively prevent these violations. They currently already try to stop account sharing through IP logging, cookie tracking, etc., but those methods are not as reliable as changing the auth mechanism altogether to something like Keyri, in which credentials are not free-floating strings that can be passed from one person to another.

Regarding OpenID: OpenID providers (Google, FB, etc.) don't see your private keys, but by registering and logging in on various services through them, you are giving those platforms yet more data about yourself. That is why these platforms provide OpenID auth services for free. This privacy threat is nebulous, but privacy-conscious people like myself don't use OpenID for this reason.

Edit: an article on OpenID privacy issues from people who know more than me: https://people.inf.ethz.ch/basin/pubs/asiaccs20.pdf. Excerpt: "s. Unfortunately OpenID Connect is not privacy-friendly: the identity provider learns with each use which relying party the user logs in to. This necessitates a high degree of trust in the identity provider, and is especially problematic when the relying parties’ identity reveals sensitive information"

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

#44
post #18

Have you considered lnurl-auth? https://github.com/fiatjaf/awesome-lnurl#lnurl-auth

That's a similar concept, though despite their claims of unphishability, it is phishable, since the QR code is portable, and that is the only item that the authenticating device reads. The contents of the QR code simply don't matter as long as it's portable (it always will be) and is the only item that the authenticator reads. Keyri reads stuff other than the QR code.

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

#45
post #35

I was immediately intrigued by the proposal, though I can't imagine ever wanting to rely on my phone to be identified (what if my battery dies? I left it in another room? hey, a customer is gone and that sale has not gone through). > They also allow users to share their subscription accounts with others, robbing companies of revenue. This made me question your motives: "robbing" is a very strong statement for somethi…

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.

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

#46

Earlier quoted context omitted.

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…

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

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

#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.

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

#50
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 asking "Hey can you verify that's you logging into our website?"

Post reply on HN