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.
Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
41–50 of 98 posts
Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#42Earlier 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?
Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#43I 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 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
#44Have you considered lnurl-auth? https://github.com/fiatjaf/awesome-lnurl#lnurl-auth
Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#45I 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…
Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#46Earlier 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…
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
#47Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#48Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#49Re: Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
#50I'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?"