Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 98 posts

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

#11

Post by jeffbarg »

thekeyper wrote: post #6
jeffbarg wrote: post #2

It's shocking to me that authentication the way WhatsApp / Discord do it is not a) commonplace and b) productized for developers. This feels like an obvious first step solution IMO - best of luck with the launch. Edit: having the standalone Keyri app work for apps that don't have a dedicated mobile app of their own feels like it would drastically increase the market size here. Auth0 / Cognito are woefully unequipped…

Thanks. Yes, the concept is to productize the WhatsApp/Discord UX. Keyri differs from them on how it works behind the scenes for increased security and ease of integration. BTW - QR login is much more prevalent in China. Just about every major and minor tech platform there has QR login. I see that as a case of leapfrogging, and I hope we can accelerate its adoption in the West and other regions. Agreed that the stand…

Super interesting re: China. Curious if there are open source projects/libraries they build on or if most of that is built internally.

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

#12

Post by thekeyper »

gabrielsroka wrote: post #3

Is it OpenID or OpenID Connect (OIDC)? (Does anyone still use OpenID?)

I used "OpenID" in the text as shorthand for OIDC. To be clear, Keyri is not OpenID / OIDC for preserving privacy and making the Keyri API a fail- and compromise-secure system.

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

#13

Post by tialaramex »

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

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

#14

Post by thekeyper »

thesimon wrote: post #9

> for example, SMS-based 2FA doesn't work when you travel abroad WiFi calling usually also supports texts over wifi. > then generates a signed authentication request using the stored private key, then sends that request to the relying party's auth server, which authenticates the user by verifying the signature using the public key it received during registration so as a customer, I need to keep track of all public ke…

> WiFi calling usually also supports texts over wifi.

True, but WiFi calling remains opt-in for most carriers (and I suspect it'll remain so given the incentives in play). I don't have stats on WiFi calling adoption, but anecdotally, most people I've asked (including my cofounder), have been SOL when traveling abroad and relying on SMS OTP

> so as a customer, I need to keep track of all public keys of my customers?

You only need to keep track of the one public key that your user generated for your service, no different than keeping track of their password. It's arguably easier to keep track of a public key than a password given you don't absolutely have to hash+salt a public key.

> So in case I get access to a Gmail account, I can get full access to the customers account.

Yes, if you manage to break in to a Google or Apple account (which is a lot harder than breaking into an account at just about any other company), you would get access to an individual's private keys, same as you would get access to all of their stored passwords, email OTP, email password recovery, text messages, photos, OIDC-connected accounts, etc.

> Is the key protected by passphrases?

Yes, developers can enable securing the keys with a user-set 4-digit PIN that the user must input upon key recovery. This is optional for developers.

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

#15

Post by tialaramex »

thesimon wrote: post #9

> for example, SMS-based 2FA doesn't work when you travel abroad WiFi calling usually also supports texts over wifi. > then generates a signed authentication request using the stored private key, then sends that request to the relying party's auth server, which authenticates the user by verifying the signature using the public key it received during registration so as a customer, I need to keep track of all public ke…

> so as a customer, I need to keep track of all public keys of my customers?

Yes. You probably want a reasonable limit. A customer might have ten phones, but if they have a hundred phones they already know they're a weirdo and you won't be the first one to tell them that. You will probably also want to have a way for customers to distinguish one from another, so that they can say "Oh I gave my old iPhone to my brother" and delete the unneeded credentials.

The good news is that as their name might suggest, they're not secrets, so now you don't need to worry about anybody stealing them. If Keyri did even a halfway competent job of this they're useless to anybody except you.

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

#19

Post by thekeyper »

wulltd wrote: post #8

Hello! Please compare this to Steve Gibsons SQRL login scheme. Are there any major differences or is this based on that project? It looks very similar on the surface

The general crypto scheme (auth based on signed requests) is the same as SQRL. Differences: (1) SQRL employs one identity that users use across multiple SQRL-enabled services. Keyri-enabled accounts are not portable/natively-shareable across different services like that - they are specific to the services users registered with (2) Users don't need to download an SQRL client on their desktop device. I see that independent developers have made iOS and Android clients, but Steve notes they currently lack certain important features (though I haven't investigated enough to know their deficiencies) (3) Our main product is an SDK that developers can embed in their own mobile apps
Post reply on HN