1
Passwords suck - they're terrible for security and terrible for ease of use. 2FA solutions are clunky and still insecure - for example, SMS-based 2FA doesn't work when you travel abroad, and it can be defeated with phishing and SIM swapping. They also allow users to share their subscription accounts with others, robbing companies of revenue. Password-based auth also enables the sort of bot activity that renders sites like Ticketmaster and StockX unusable for real customers.
2FA methods currently in the market represent a tradeoff between security and ease of use. Secure 2FA methods like USB keys are a pain to use, while easy 2FA methods like SMS passcodes are unsecure. Keyri essentially takes the USB key concept and puts it in users' phones. This is hard to do in a secure way while maintaining a seamless UX due to the need for two-way communication to prevent phishing. Some enterprise-focused smartphone-based passwordless solutions require a Bluetooth or WiFi connection between users’ phones and their other devices to ensure security, which is obviously untenable for rollout to mass audiences. Our system works securely 100% over HTTPS and computer vision (beyond just reading QR codes). An additional difficulty is that companies don't want to force their users to download a third-party app. We solve this with our SDK that allows companies to bake our passwordless auth capability into their apps.
Keyri replaces passwords with public key cryptography plus biometrics. Instead of remembering and typing in your credentials, authentication happens by just scanning a QR code (on desktop web) or tapping a button (on mobile web and mobile native apps). Thanks to biometrics and cryptographic functions happening in the background, multi-factor authentication happens in one step that takes less than a second.
At registration, the Keyri SDK generates a key pair, stores the private key in the phone's secure enclave, and sends the public key to the relying party's (our customer’s) credential server. At login, the SDK first verifies the user's identity via biometrics (Face ID etc.), 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. The user's private keys never leave their phone. There's a lot more cryptography, handshakes, secret sauce, etc. that happen during the auth flow, but those are incidental to the core concept outlined above.
What's different about us? 1. Keyri is available as a mobile SDK, allowing any company to offer passwordless onboarding and WhatsApp-like QR code login entirely within their own app without a long and tricky dev cycle. 2. Keyri doesn't require any typing or setup / opt in. Other passwordless solutions require typing out a username/email address and/or connecting by bluetooth, specialized onboarding, etc. 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.
We charge companies based on how many unique users use Keyri to log in to their web services in a given month. We can provide our API in a self-hostable format for companies in heavily regulated industries. Our auth endpoint code is open source, but our API and mobile SDK are not.
If you want to try the experience, check out our live demo here: https://keyri.co/demo. Note that this demo uses our standalone authenticator app, which is available for companies that don’t have their own mobile app, but our main product is the white label SDK that incorporates the authenticator app’s full functionality (and then some) into our customers’ apps.
As a long-time HN lurker, I know the community has expertise and strong opinions on authentication. It would be great to get your feedback, and I’d be happy to answer any questions. We’re very actively building out the system, so any ideas for bolstering our system are welcome.