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"
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).
(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?).
> ... 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.
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.
> 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 :)
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).
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)
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.
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"