[u801e]

> Your average user is not going to open a command prompt and dig into Openssl.

That's why I said that the browser should provide that feature.

> There are (or were, I haven't used them for a decade) browser-specific APIs for generating private keys locally, but they were very flakey, and the whole UX was very confusing for users.

That's a UX issue that can be solved if the time was put into it

> And after this, the user can only sign in on the machine in which the key was created. Your average user will not have a clue how to move certificates and keys around between machines.

They shouldn't be moving/sharing keys between machines at all. What could be done is to implement a mechanism to associate an additional device with the account. Perhaps something like sending a CSR from the new device and then using the first device to confirm that it's a legitimate request.

[thw0rted]

> something like sending a CSR from the new device and then using the first device to confirm that it's a legitimate request

So I can only sign into my account from any new machine if I have access to a previously-signed-in device? What happens if my last login session expires? At that point, I have to sign in with a password, and now I'm back to all the terrible things about managing 500 passwords.

Federated identity / SSO through a trusted provider makes so much more sense, the standards are open and there are dozens of implementations available. Nobody needs to reinvent the wheel, we don't need a 15th standard. You just have to sign in with a provider that you trust not to lock you out for no reason, in a way that gives you no recourse (unless you can get your story on the front page of HN). Obviously that provider is not Google.

[u801e]

> So I can only sign into my account from any new machine if I have access to a previously-signed-in device?

The scenario I'm envisioning is that one creates an account on a website like HN, but with the additional step of generating a CSR, sending it, and receiving a certificate to store locally (with the browser handling the generation of the CSR and storing the resulting certificate with a standard and easy to understand UX workflow).

Once signed into the account, the website could prompt the user to add additional devices if they so wish (e.g., I created the account and signed in on my laptop, now I'll add my smartphone as a trusted device). This step could be done now, or sometime in the future.

If the prompt encourages users to do so right after creating the account, it's likely that they'll have access to the original device to confirm additional CSRs. Even if they choose not to do so right away, I don't think it's an unreasonable requirement to have access to the original device.

> What happens if my last login session expires? At that point, I have to sign in with a password, and now I'm back to all the terrible things about managing 500 passwords.

If the situation was that websites used 2FA via having the username/password as one factor and client-side TLS as the second factor, then password reuse wouldn't be an issue. Even if someone were to guess the username/password combination, the most they could do is send junk CSRs to try to add their device, which can then get rejected or not acknowledged by the original account holder.

> Federated identity / SSO through a trusted provider makes so much more sense

Perhaps, but based on what I've seen for general services out there, they just use either Google and/or Facebook as the trusted provider. I'm not sure how that situation came about, because it was pretty easy to create multiple accounts on those services without having to provide any basic identifying information (which essentially is the antithesis of what should be considered a trusted provider).

SSL/TLS is a standard that has been around for a long time, and given the ubiquitous use of server-side TLS, I don't see why it would be considered re-inventing the wheel to use the client side part of it. With nginx, you could set a HTTP header with proxy_set_header based on the value of the $ssl_client_verify variable value. Then the application could direct the user to the login page. If the client-cert is valid, then allow them to log in normally. If not, then direct them to log in, send a CSR, and go back to a valid device to confirm that CSR.

> You just have to sign in with a provider that you trust not to lock you out for no reason, in a way that gives you no recourse (unless you can get your story on the front page of HN). Obviously that provider is not Google.

Personally, I think we shouldn't have to involve third party providers in the authentication process. One reason is what you've already mentioned about getting locked out of the account. The second is if that account is compromised. With TLS, you don't need a third party involved in the process at all for the client side.

I just find it disappointing that I'm essentially forced to use email or SMS based 2FA where, arguably, those are less secure compared to having a strong password on the original service. By less secure, I mean that those factors could be compromised in a way to access my account that completely bypasses my strong password. It's the same with requiring security questions and allowing access to the account via a well known answer to one or more of those questions.