Launch HN: Keyri (YC S21) – Secure smartphone-based passwordless authentication
97 comments
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 for most web app's authentication needs, so there's still a huge opportunity there.
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 for most web app's authentication needs, so there's still a huge opportunity there.
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)
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)
Super interesting re: China. Curious if there are open source projects/libraries they build on or if most of that is built internally.
I don't have much inside info, but the contents of the QR codes on Alibaba, JD.com, and others differ substantially, so I suspect each is building their systems in-house, though in China, I would think there's more of an established playbook for building them given its prevalence. I haven't run across a dedicated library/package for this.
In the West, WhatsApp and Discord have massively different schemes for QR login.
In the West, WhatsApp and Discord have massively different schemes for QR login.
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.
Do I understand your design right in that private keys are backed up to Google Drive or iCloud?
Giving all my login information to a third party seems like an awful idea. How are the keys secured from Google and Apple?
What is the contingency plan for logging in if your biometrics change? People lose fingers sometimes.
Giving all my login information to a third party seems like an awful idea. How are the keys secured from Google and Apple?
What is the contingency plan for logging in if your biometrics change? People lose fingers sometimes.
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.
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.
[deleted]
Congratulations on the launch, Zain and Grant.
I've come across a decent share of passwordless solutions in recent times (like gazepass.com and sawolabs.com to name two of the recent upstarts in the space), while GRC's SQRL has been around a lot longer.
The bane of passwordless auth systems is the whole ceremony around forgot-password / change-password flows (in this case, re-associating a new public/private keypair, on device loss, or on device change). Keybase solved the latter scenario by storing the TripleSec-wrapped keypair with a user-supplied password [0]; though, in a system we designed for our use, we use OPAQUE (password-based) to keywrap the material [1], while Signal recently demonstrated a rather elaborate scheme (passphrase-based) for tucking away user secrets [2]. SQRL solved the former in a rather unconventional way by treating DHKE as a two-way hash function [3], while Keybase has (IIRC) various recovery scenarios due to the nature of their service.
How does keyri.co handle these two scenarios? Backups don't help in cases where private-keys are compromised. Besides, some might even question the security behind backing-up private-keys to Google/Apple in the first place. I, personally, consider it an unacceptable compromise: Using an intermediary like evervault.com / scrt.network may be slightly better (or even MPC [4])?
If I may, I'm kind of curious about the cryptography involved when the authentication is delegated via the QR code. We designed ours based on the Keybase KEX [5] secured over a CPACE session [6].
Thanks.
[0] https://archive.is/XosXO
[1] https://archive.is/zmpxv
[2] https://archive.is/3sTZR
[3] https://archive.is/H72o2
[4] https://archive.is/Ojz9U
[5] https://archive.is/46VzS
[6] https://archive.is/4F1lp
I've come across a decent share of passwordless solutions in recent times (like gazepass.com and sawolabs.com to name two of the recent upstarts in the space), while GRC's SQRL has been around a lot longer.
The bane of passwordless auth systems is the whole ceremony around forgot-password / change-password flows (in this case, re-associating a new public/private keypair, on device loss, or on device change). Keybase solved the latter scenario by storing the TripleSec-wrapped keypair with a user-supplied password [0]; though, in a system we designed for our use, we use OPAQUE (password-based) to keywrap the material [1], while Signal recently demonstrated a rather elaborate scheme (passphrase-based) for tucking away user secrets [2]. SQRL solved the former in a rather unconventional way by treating DHKE as a two-way hash function [3], while Keybase has (IIRC) various recovery scenarios due to the nature of their service.
How does keyri.co handle these two scenarios? Backups don't help in cases where private-keys are compromised. Besides, some might even question the security behind backing-up private-keys to Google/Apple in the first place. I, personally, consider it an unacceptable compromise: Using an intermediary like evervault.com / scrt.network may be slightly better (or even MPC [4])?
If I may, I'm kind of curious about the cryptography involved when the authentication is delegated via the QR code. We designed ours based on the Keybase KEX [5] secured over a CPACE session [6].
Thanks.
[0] https://archive.is/XosXO
[1] https://archive.is/zmpxv
[2] https://archive.is/3sTZR
[3] https://archive.is/H72o2
[4] https://archive.is/Ojz9U
[5] https://archive.is/46VzS
[6] https://archive.is/4F1lp
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.
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.
Thanks! Btw, is keyri short for key-ring? In my native tongue, Gujarati, it means "Ant".
All the best.
All the best.
haha - you guessed it! Draft 0.1 was to be named Keyri while owning the .ng domain name to create Keyri.ng. We opted against the Nigerian domain but kept Keyri.
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
> 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 keys of my customers?
> Key backup and recovery is handled automatically via the cloud (iCloud / Google Drive)
So in case I get access to a Gmail account, I can get full access to the customers account. Is the key protected by passphrases?
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 keys of my customers?
> Key backup and recovery is handled automatically via the cloud (iCloud / Google Drive)
So in case I get access to a Gmail account, I can get full access to the customers account. Is the key protected by passphrases?
> 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.
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.
>> 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
Is this rate limited by the phone for access to the secret key?
> 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
Is this rate limited by the phone for access to the secret key?
Yes, when developers enable passcode protection, the guess rate limiting is based on the OS default because it's accessing the same subsystem responsible for unlocking the phone itself.
> 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.
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.
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...
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.
So how do you support people without smartphones?
Our system does not support people without smartphones, which is why we are addressing companies that are mobile-first or generally have more tech-forward userbases with ~100% smartphone adoption. For mobile-first platforms in particular, our system helps them flesh out a "WhatsApp-like" auth UX, which is industry leading in our opinion, without a long development cycle.
That's kind of limiting and exclusive. It sounds great for the next Clubhouse or Yo, but it seems like a dead end for anything serious like banking or any service that takes inclusion and disabilities serious.
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.
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.
You referred to 'QR + CV + HTTPS system'. Is there more to the CV component than taking a photo?
Yes, there's more to it than just reading the QR code. As mentioned above, I don't think it's a very defensible tech differentiator right now (lots of better-funded cybersecurity companies out there), but in summary, the phone sees stuff on the screen other than the QR code.
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 for them to scan instead so that you're signed in as them and like I said, if Keyri does that then I don't see how.
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 for them to scan instead so that you're signed in as them and like I said, if Keyri does that then I don't see how.
> 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 for them to scan instead so that you're signed in as them...
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.
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.
> am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 relying on BLE, USB, NFC to prove user-presence?
FIDO2 isn't interested in this problem at all. From the point of view of FIDO2 the rpId ("Relying Party ID" the thing that distinguishes Apple from Facebook) is just arbitrary data selected by the application.
WebAuthn solves the problem by trusting the web browser to know which web site you're visiting. Specifically, the relying party (a web site you're trying to sign into) gets to pick a DNS name you'll authenticate against but the browser matches this DNS name against the HTTPS URL you're looking at, and rejects requests that don't match. The rpId is based on this DNS name, so a phishing site can't work.
e.g. You may think this page is from your bank, but your browser knows it's https://fake-bank.example/ and won't give it WebAuthn credentials for real-bank.example even though you firmly believe that's where you are.
FIDO2 isn't interested in this problem at all. From the point of view of FIDO2 the rpId ("Relying Party ID" the thing that distinguishes Apple from Facebook) is just arbitrary data selected by the application.
WebAuthn solves the problem by trusting the web browser to know which web site you're visiting. Specifically, the relying party (a web site you're trying to sign into) gets to pick a DNS name you'll authenticate against but the browser matches this DNS name against the HTTPS URL you're looking at, and rejects requests that don't match. The rpId is based on this DNS name, so a phishing site can't work.
e.g. You may think this page is from your bank, but your browser knows it's https://fake-bank.example/ and won't give it WebAuthn credentials for real-bank.example even though you firmly believe that's where you are.
> Isn't this a problem then with WhatsApp Web login too
Yes, it's an issue with WhatsApp QR login and every other QR login implementation.
> I was also wondering if its a severe vulnerability
It can be severe if the attacker only needs to be authenticated in the victim's account for a short while to do damage. For example, to withdraw cryptocurrency from an exchange account. Or, in the case of WhatsApp, to extract damaging personal info. Persistent access is not a prerequisite for the ability to do harm.
> Am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 by relying on BLE, USB, NFC to prove user-presence
Partially correct - there's two-way communication in FIDO2/CTAP2 in which the roaming authenticator confirms the "identity" of the web session before sending an auth request. The user-presence aspect is incidental to these three protocols. We do the same thing, just with CV
Yes, it's an issue with WhatsApp QR login and every other QR login implementation.
> I was also wondering if its a severe vulnerability
It can be severe if the attacker only needs to be authenticated in the victim's account for a short while to do damage. For example, to withdraw cryptocurrency from an exchange account. Or, in the case of WhatsApp, to extract damaging personal info. Persistent access is not a prerequisite for the ability to do harm.
> Am I correct in guessing that FIDO2 solves this "trust gap" problem with CTAP2 by relying on BLE, USB, NFC to prove user-presence
Partially correct - there's two-way communication in FIDO2/CTAP2 in which the roaming authenticator confirms the "identity" of the web session before sending an auth request. The user-presence aspect is incidental to these three protocols. We do the same thing, just with CV
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.
[deleted]
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?
Yes, even if bad actors figured out the secret sauce, they couldn't defeat it easily. It's possible, but if they hack you the way they'd have to hack you in order to defeat our CV element, you'd have much bigger problems to worry about. So yes, the lack of disclosure is for competitive reasons, not for security purposes.
[deleted]
[deleted]
Have you considered lnurl-auth?
https://github.com/fiatjaf/awesome-lnurl#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.
Saas pass has a similar offering for developers for over 5 years. We need more such initiatives like yours to help raise awareness that there are passwordless options out there.
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.
It seems as though every SaaS provider is already rolling their own authentication app - my iPhone is becoming crowded with them (Xero, Adobe, etc) - so the timing of Keyri is fantastic.
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.
iOS screenshots: “Log in Two Accounts”
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 :)
[deleted]
I 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 something like sharing accounts — even if you are in that extortionist camp that likes to get every last cent out of the customer, I wouldn't advertise it as widely.
Why do you feel that companies should be worried about people sharing accounts with people they have enough trust in to share accounts (and devices like your phone) with?
It's also the first time I read that OpenID requires somebody else to see your private keys, or to share any private data that you do not wish to share: can you elaborate on that?
> 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 something like sharing accounts — even if you are in that extortionist camp that likes to get every last cent out of the customer, I wouldn't advertise it as widely.
Why do you feel that companies should be worried about people sharing accounts with people they have enough trust in to share accounts (and devices like your phone) with?
It's also the first time I read that OpenID requires somebody else to see your private keys, or to share any private data that you do not wish to share: can you elaborate on that?
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"
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"
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 average).
As I said in a comment below, the fact that companies "can afford" is not the same as "it's worth it" to them, and per-seat pricing is "robbing" those customers when there is no increased value for the customer or increased cost to the provider: make a product that's valuable to be per-seat, and customers will pay for it (sure, some who can't afford it won't, but that's not lost revenue anyway)!
Finally, with OpenID, I can set up my own identity provider, or use a privacy conscious one. Unfortunately, almost no web sites accept pure OpenID (they did for a while ~10 years ago), but instead only a limited set of "large" providers. However, a company can easily decide to support arbitrary OpenID providers instead of just Google SSO or Keyri, and then users can choose how much they care about their privacy and use an appropriate provider.
In short, web sites are not implementing OpenID authentication, but instead somewhat-custom SSO through Google/Facebook that mostly uses OpenID Connect (Oauth) protocol for authorization (in a way, it could be any other protocol that preserves the security properties of OpenID Connect).
As I said in a comment below, the fact that companies "can afford" is not the same as "it's worth it" to them, and per-seat pricing is "robbing" those customers when there is no increased value for the customer or increased cost to the provider: make a product that's valuable to be per-seat, and customers will pay for it (sure, some who can't afford it won't, but that's not lost revenue anyway)!
Finally, with OpenID, I can set up my own identity provider, or use a privacy conscious one. Unfortunately, almost no web sites accept pure OpenID (they did for a while ~10 years ago), but instead only a limited set of "large" providers. However, a company can easily decide to support arbitrary OpenID providers instead of just Google SSO or Keyri, and then users can choose how much they care about their privacy and use an appropriate provider.
In short, web sites are not implementing OpenID authentication, but instead somewhat-custom SSO through Google/Facebook that mostly uses OpenID Connect (Oauth) protocol for authorization (in a way, it could be any other protocol that preserves the security properties of OpenID Connect).
> ... per-seat pricing is "robbing" those customers when there is no increased value for the customer or increased cost to the provider
A good example of a company doing that is Zendesk: as an engineer, I want to make a comment on a support ticket once every 3-6 months, but Zendesk would require my company to pay for another user license to do that. That's not value provided nor is there a cost for them in having another non-read-only account. They are attempting to rob their customers instead.
A good example of a company doing that is Zendesk: as an engineer, I want to make a comment on a support ticket once every 3-6 months, but Zendesk would require my company to pay for another user license to do that. That's not value provided nor is there a cost for them in having another non-read-only account. They are attempting to rob their customers instead.
Eliminating account sharing does not preclude offering the ability to share seats. Zendesk could very well offer their customers a way to provision users like you a limited account or some other mechanism that allows commenting on a support ticket every now and then. For example, Netflix offers a mechanism to formally invite members of your household to your account for free, which is the scope of "account sharing" that they allow in their TOS.
Either way, it's in Zendesk's and Netflix's best interest to make sure that a given account is used only by the person they were told would use it when the account was purchased, both from a business perspective and a security perspective. How they can address the needs of their customers while enforcing their stated TOS with a mechanism like Keyri is up to them.
Either way, it's in Zendesk's and Netflix's best interest to make sure that a given account is used only by the person they were told would use it when the account was purchased, both from a business perspective and a security perspective. How they can address the needs of their customers while enforcing their stated TOS with a mechanism like Keyri is up to them.
> 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?).
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?).
> 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.
While you should certainly hope that this is just a "transition step", I am sure you are treating it as a business risk as well: companies will frequently have people who are downgrading their security and convenience by moving to Keyri (eg. people like me :), and they will always push back. After a while, those companies might decide that it's not worth it to keep both options available, Keyri will be the one to go (some will, of course, decide otherwise). I am sure you will be tracking this, but it's worth pointing out that this risk is there and not insignificant :)
While you should certainly hope that this is just a "transition step", I am sure you are treating it as a business risk as well: companies will frequently have people who are downgrading their security and convenience by moving to Keyri (eg. people like me :), and they will always push back. After a while, those companies might decide that it's not worth it to keep both options available, Keyri will be the one to go (some will, of course, decide otherwise). I am sure you will be tracking this, but it's worth pointing out that this risk is there and not insignificant :)
Account sharing is never unethical. It's my account and I'll damn well give access to whoever I please. Services such as Netflix mitigate this by limiting the amount of concurrent use, which is fine.
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 indicated (and as people have multiple devices these days, it should never be limited to one-at-a-time).
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 indicated (and as people have multiple devices these days, it should never be limited to one-at-a-time).
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.
It's a fair point for any service. If the service doesn't actually provide a service they can control concurrent access to, then it doesn't cost them anything. So you're literally just trying to scam your customers. Gross.
> 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)
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.
The pricing page is very offputting to me. The first is free, but scaling starts and ends with "contact us"? Not the sort of thing I'd invest in, if I was in the market for such a thing. That's just my take though.
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.
I'm having trouble with the demo... registration and login flows both end in a screen that says "Select a Kyri service Manager account to login" but has no list of accounts. Email in profile if you don't want to troubleshoot this publicly.
Sent you an email. Anyone else - please let me know if you're having trouble with the demo here or email me - [email protected]
What’s the process for when a user gets a new phone? I dread getting one because my keys depending on the phone completely disappear and have no transfer mechanism.
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).
(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).
So, if a user changes from Android to iOS or vice versa, there's no (automated) path for continued service?
Correct, that's currently the case. Users can use QR code backup/restore functionality if enabled by the developer to switch between iOS and Android. That would have to be done app-by-app. We're working on our own cloud backup system to automate this.
I think such transitions between smartphone OSs already entail significant credential transfer issues, since saved passwords also do not automatically move between OSs.
You'd have similar problems if you used "Sign in with Apple" for an app on an iOS device and then switched to Android.
I think such transitions between smartphone OSs already entail significant credential transfer issues, since saved passwords also do not automatically move between OSs.
You'd have similar problems if you used "Sign in with Apple" for an app on an iOS device and then switched to Android.
Built this 4 yrs ago, YC said no. I made both API & SDK too. Good luck.
Thank you, great minds think alike!
Looks intriguing, but do I have to take a picture every time I log in? That seems inconvenient.
I'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?"
I'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?"
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.
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.
Does this use hyperledger aries?
https://www.hyperledger.org/use/aries
https://www.hyperledger.org/use/aries
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.
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.
Thankyou for taking the time to respond, and congratulations on the launch!
Aries leverages, Decentralized Identifiers[1] with Verifiable Credentials [2]
the "ledger" is where the public keys are stored. eg it could be a permission-ed ledger, similar to SSL certs only known/<want to be known> parties would publish their keys to the chain.
Example: Sovrin network [3]
Or could be permission-less, maybe focused more towards IoT/whatever
Example: ION Network [4] coming out of Microsoft.
The ledger is not a requirement to establish an identity as shown with the did:peer [5] method
Frankly I think the usage of blockchain was more to get on the marketing bandwagon at the time. Messaging is now moving from "blockchain" to "distributed ledger"
1 - https://www.w3.org/TR/did-core/
2 - https://www.w3.org/TR/vc-data-model/
3 - https://sovrin.org/
4 - https://identity.foundation/ion/
5 - https://identity.foundation/peer-did-method-spec/index.html
Aries leverages, Decentralized Identifiers[1] with Verifiable Credentials [2]
the "ledger" is where the public keys are stored. eg it could be a permission-ed ledger, similar to SSL certs only known/<want to be known> parties would publish their keys to the chain.
Example: Sovrin network [3]
Or could be permission-less, maybe focused more towards IoT/whatever
Example: ION Network [4] coming out of Microsoft.
The ledger is not a requirement to establish an identity as shown with the did:peer [5] method
Frankly I think the usage of blockchain was more to get on the marketing bandwagon at the time. Messaging is now moving from "blockchain" to "distributed ledger"
1 - https://www.w3.org/TR/did-core/
2 - https://www.w3.org/TR/vc-data-model/
3 - https://sovrin.org/
4 - https://identity.foundation/ion/
5 - https://identity.foundation/peer-did-method-spec/index.html
Understood, thanks. I think the concept is excellent - truly a digital ID card that you can present with a simple cryptographic token, thus a real "proof of identity". Keyri is "proof of ownership of a trusted device", which, while being a narrower concept, we believe is more palatable from a go-to-market perspective, since companies prefer to proof identities in their own proprietary way.
I agree, the worst part of the Aries project is the extreme egos associated with it - but i do really like the ideals.
Another example of over reach: Trust over IP [1]
Again congratulations of the launch, I am not advocating Aries but I am very interested. Especially the intersection of actual users (what you are doing) / pie-in-the-sky ideals
I wish you both the best :)
1 - https://trustoverip.org/
Another example of over reach: Trust over IP [1]
Again congratulations of the launch, I am not advocating Aries but I am very interested. Especially the intersection of actual users (what you are doing) / pie-in-the-sky ideals
I wish you both the best :)
1 - https://trustoverip.org/
Appreciate the detail. It's quite helpful. Thanks very much!
CyberArk already does this... it's called Vendor Privileged Access.
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.
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.
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...
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.
Thank you, Hope to see Keyri there!
Unfortunately, this enables vendors to prevent fair-use account sharing, and it looks like to implement some sort of DRM. My team at a small company used SurveyMonkey and only allowed two devices to login, and we paid for only one user license. However, our position was split into two part-time jobs; hence the pricing would have been unfair. I think your service is a good solution, as long as SaaS providers implement more reasonable licensing models.
I think usage-based pricing is more fair than per-seat pricing, and it makes much more sense for SurveyMonkey than per-seat pricing. Usage-based pricing also eliminates account sharing concerns because a given customer can provision as many accounts to their employees or friends/family as needed.
> 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!
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!
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.
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.
Why not use the SIM for two factor authentication. That's what is used in Scandinavia with BankID.
SIM swapping is relatively common in the US because it's not difficult to execute via social engineering. I'm not sure what the situation / protections against SIM swapping are in Scandinavia. https://en.wikipedia.org/wiki/SIM_swap_scam
A replacement SIM card will only be delivered to your registered address. I'm not sure that SIM swapping would even be an effective attack vector because the user will have to register that SIM card with the bank or other institution before it will work. I think, but I;m not sure, that all SIM cards have unique IDs.
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.