Live data from Hacker News

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

news.ycombinator.com

81–90 of 98 posts

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

#81
> 3. Key backup and recovery is handled automatically via the cloud (iCloud / Google Drive). Additional backup/restore options are available in our SDK. 4. Privacy: unlike OpenID and some other passwordless solutions, Keyri’s server does not store or see any private keys or any personal information. Our API simply facilitates the transmission of public keys and encrypted signed authentication requests

I was curious if you could speak more to this. There seems to be some tension between:

"Key backup and recovery is handled automatically via the cloud" and "Keyri’s server does not store or see any private keys or any personal information" but maybe I'm missing something. How can you do backup/recovery if you never see the private keys? Is there some kind of trusted reset functionality?

Thanks, and congrats on launching!

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

#82
post #71

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…

Thanks for the response. The way I use passwords is way safer than Keyri, so not having the option limits those extra security conscious users (you have certainly heard of hardware OTP devices like Yubikeys). Sure, you are likely right that on-average, Keyri-like approach is more secure (just like biometrics), and that's definitely where your potential for business lies (with companies looking to increase that averag…

> The way I use passwords is way safer than Keyri

I don't see how that is possible.

(1) Keyri private keys cannot be stolen other than through smartphone malware, which is exceedingly rare, while password managers and older USB keys are vulnerable to desktop malware, which is much more common - both credential stealers and, in the case of older generations of Yubikeys, keyloggers. Hardware OTP devices are additionally vulnerable man-in-the-middle phishing attacks (though the HN audience is generally savvy enough to not fall for phishing) - https://github.com/kgretzky/evilginx2.

(2) As long as you rely on passwords and TOTP, you're relying on the shared secret paradigm and trusting the relying party to handle your credentials properly. If the relying party's credential store is breached and the credentials were improperly stored (common even today), your credentials (both your password and OTP secrets) can be used by a bad actor to access your account. Public key systems like Keyri and FIDO2 substantially reduce this risk.

> As I said in a comment below, the fact that companies "can afford" is not the same as "it's worth it" to them

Please see my response below regarding account sharing. In short, eliminating account sharing in order to enforce TOS is an opportunity to (a) improve security (b) improve UX in cases where provisioning multiple users access to one account is warranted.

> Finally, with OpenID, I can set up my own identity provider, or use a privacy conscious one.

As you note, the vast majority of web services don't support arbitrary identity providers or use privacy conscious ones. History has proven that people don't set up their own identity provider. Additionally, the universe of "privacy conscious" OIDC providers is limited (non-existent?).

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

#83

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…

> Wherever you have 2FA enabled (other than email magic link), you are generally SOL if you lose your phone. I realize this is not exactly widespread (neither on the user nor the provider site), but as we are on HN: Luckily security keys exist and are cheap enough to have backups. I hate having to use my phone for 2FA (but also realize that I’m in a tiny minority there)

Fair point. As you implied, security key adoption, particularly for the consumer-facing web, is very low, as is support for more secure security keys (FIDO2) by consumer-facing web services. We're trying to bring that level of security to mass audiences through a simple UX that a minority audience (that dislikes relying on phones for authentication) may dislike. That said, we think our phone-based auth security and UX are better than those of SMS OTP, TOTP, and push notification verification, so hopefully we can convince that audience over time.

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

#84
post #81

> 3. Key backup and recovery is handled automatically via the cloud (iCloud / Google Drive). Additional backup/restore options are available in our SDK. 4. Privacy: unlike OpenID and some other passwordless solutions, Keyri’s server does not store or see any private keys or any personal information. Our API simply facilitates the transmission of public keys and encrypted signed authentication requests I was curious i…

Thanks, this question touches on a very significant point.

Backup and recovery currently are handled by iCloud and Google Drive through Keychain and KeyStore, respectively, both of which form the backbones of Apple and Google password managers, respectively. The two cloud backup services (a) are fully encrypted both in transit and at rest and (b) are managed by Apple and Google, not Keyri. So the only parties that "see" the private keys are the user and Apple or Google, and the latter two only see encrypted copies of the keys, same as they only see encrypted copies of their users' saved passwords. Recovery also happens through Apple or Google when a user sets up their new phone using iCloud / Google Drive backups of their old phones, which are also encrypted in transit and at rest. Developers can additionally require users to enter a pre-specified passcode in order to decrypt their private key upon recovery, which involves another layer of local encryption.

Key pairs are generated locally on the device (i.e., Keyri's API does not generate/provision them). Private keys are stored encrypted at rest in phones' secure enclaves and only decrypted at run time once biometric verification is passed.

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

#85
post #70

Earlier quoted context omitted.

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.

Going from "there are...many services" to "sharing accounts is robbing companies" is what I am having a problem with. That per-seat pricing "because companies can afford it" is robbing customers instead! Hey, you are selling on the internet, do not make up "costs" just to increase your revenue. I am fine with restricting simultaneous usage where there is an actual cost to it (eg. streaming) as long as that's clearly…

The contention on account sharing is "robbing companies of revenue". It is not related to additional costs imposed on companies due to account sharing. A non-negligible number of people engaged in account sharing are enjoying real value from the service(s) they are not paying for and would pay for if they could not account share. Hence account sharing enables the loss of potential revenue. As stated in another reply, if a company sees value in allowing customers to share accounts, they can build provisioning mechanisms that align with their TOS as Netflix has done.

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

#86

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

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.

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

#87

Congratulations on the launch of Keyri! I run a problem validation platform and the need-gap in 'Password less authentication' is being tracked here[1]. You're welcomed to explain how Keyri addresses that need-gap so those who need it can find it easily. [1] https://needgap.com/problems/49-password-less-authentication...

Thanks, will do! That's a clever platform.

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

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

It's unphishable because the keys used for each domain are different.

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

#90

Earlier quoted context omitted.

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?
Post reply on HN