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

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 standalone Keyri app has its place in our longer term strategy, especially when it comes to workforce SSO applications. We're currently targeting the consumer-facing web, and the roadblock we've heard from companies we've spoken to there is that it's easier for them to ask their users to "download the Google Authenticator app" or "download the Duo app" than it is to "download the Keyri app". It's a matter of our fledgling legitimacy at this point, though we hope to get to a point where users can accept and prefer the Keyri app (because the UX and security really are better than Google Authenticator / TOTP apps)

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.

Private keys are backed up via iCloud Keychain (on iOS) and Android KeyStore (on Android). Both are encrypted systems and are the backbone of Apple and Google password managers, respectively.

On the device, private keys live in the phone's secure enclave, usually backed by a hardware security module. When you get a new phone, these keys can only be restored when you set up the new phone from a backup of your old phone - thus, the security of the private keys in the Keyri system is on par with the security of Apple / Google password managers as well as smartphone cloud backups in general, which is pretty good.

Other authenticator apps, like Google Authenticator, Duo, etc. use these same backup methods. Others, like Authy, maintain their own cloud backup systems.

That said, I agree cloud backups are not ideal, but I think they're necessary to maintain a smooth UX for most users. Our SDK provides developers the option to disable cloud backups and instead enable QR code backups, which allow users to export their private keys onto a QR code that they can print out and keep somewhere safe, like where they keep their passport.

In case biometrics fail, (1) we give developers an option to enable a PIN fallback. Some apps like Credit Karma do this today. (2) Companies can have their own "I lost my finger" customer support process and allow users to reset their credentials upon approval. I suspect that process will see less traffic than "I forgot my password", so it should (a) cut down on CS costs and (b) make it easier to detect social engineering attempts.

Thanks very much for the heavily referenced post. As an aside, I built the prototype of this last year in a vacuum without knowing any passwordless solutions other than FIDO2 systems. My cofounder disabused me of the notion that this was a totally novel concept. I'd never heard of gazepass or sawolabs before and now feel even less original :). That said, I think you recognize the differences between our system and those two, so I won't get in to those details unless you want me to.

Agreed, device continuity is the #1 challenge for truly passwordless systems. The Google/Apple cloud backup system we're currently on is a compromise to deliver a seamless UX for mass audiences in the majority of device transition cases. As soon as a user sets up their new phone using an iCloud / Google backup of their old phone, they will have Keyri private keys already embedded in their restored apps. Developers, optionally, can require users to input a PIN/passcode in order to restore the keys following a backup restoration.

For the minority of cases in which this cloud-backup-based device transition does not work smoothly, companies can offer customer support lines, which, as mentioned in another reply, will be far less busy than "forgot my password" CS lines, thereby making social engineering easier to detect.

Again, while not ideal, as mentioned in another reply, the current solution is based on Keychain (iOS) / KeyStore (Android), which are rather secure and private, and compromise of those systems entails... a really bad day for the victim given they're associated with saved passwords, emails, text messages, photos, etc.

And yes, we definitely plan to maintain our own cloud backup service. That is really hard to architect in a way that's both secure and frictionless, so we'll be designing that for some time. Evervault and scrt.network are great references - thank you.

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

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

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

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 other screen they're sitting in front of via our QR + CV + HTTPS system.

Deploying WebAuthn / FIDO2 on desktop web/native apps is far more challenging given the standard's need for communication between the authenticator device and client device to happen via USB, Bluetooth, or NFC. USB is obviously out of the question for consumer-facing apps, and companies simply can't ask typical users to connect their devices via Bluetooth - setup and reliability are the UX issues with BT.

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.

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.

Just checked out SaaS pass and it is definitely a robust "auth in a box" solution. Thank you, yes ultimately the goal is to eliminate account takeovers and consumer headaches - we think we have the ideal solution but also look forward to other players pushing the passwordless agenda forward.

Thanks very much! Yes, agreed, the number of authenticator apps is becoming annoying at best and arguably daunting - not to mention the prevalence of "sign in with ___" which has left consumers confused about whether they've leveraged Google, Facebook, Apple, Xero, Github, Discord, etc for each service.

Ah yes, thanks for pointing that out. The iOS app store listing is ancient and terrible. The Google Play store listing is a bit better, but still from a time when I was doing all the design work :)

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"

That's a fair point and something we're definitely looking into. Ultimately, if you are interested in our SDK, we'll need to have an implementation conversation and can discuss pricing at that time, but it's definitely something we're considering updating. Thank you for the feedback.

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

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

Thank you, great minds think alike!

What was it called?

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.

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.

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.

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