5 ms·

Can anyone tell me why we do not have a mechanism like SSH keys to authenticate to websites? Genuinely curious.

tastroder 6y ago
As arpa mentioned in the other thread, client certificates are a thing. Outside of corporate infrastructure the implementation is somewhat painful though and OS/browser sides far from optimal in terms of user experience.
- indigo945 6y ago
  Yes, and browser vendors have refused to enhance support for this. To be fair though, client certificates have some obvious downsides, before all that you only have them on the device where they have been created. Since most people use several devices (desktop/notebook/tablet/phone) throughout the day, you require some way to keep them in sync. Cloud services could solve this, but tend to be vendor-specific, and doing it by hand via sneakernet is painful. Then this same problem occurs all over again if a certificate is leaked, for example due to device theft, and the cert needs to be revoked and replaced. In summary, while browser and mobile OS vendors could cooperate to improve the situation with client certificates, as of now, there appears to be no interest from any party to do so, and unless it happens, it is not worth it to use client certificates at all.
  - nybble41 6y ago
    > Since most people use several devices (desktop/notebook/tablet/phone) throughout the day, you require some way to keep them in sync. The obvious solution, rather than syncing the certificates, would be to allow more than one client certificate per account. Each device would have its own certificate. If one device is compromised you need only revoke that particular certificate; other devices could still access the account. To avoid the need to manually register multiple certificates for each account you could cross-sign the per-device certificates; i.e. if key A is registered, and key B is signed by key A, then key B can also be used to sign in, perhaps with a warning sent to the owner of the account about a login from a new device.
- tialaramex 6y ago
  Cryptographic certificates bind a key to an identity. But, that's not really what we want in this scenario (notice how your SSH keys aren't bound to an identity) so immediately alarm bells should be going off. One option is each site you authenticate to needs to issue you a certificate for your identity on that site. Web browsers would presumably become responsible for minting the CSR during registration, and then hanging on to however many private keys and certificates (dozens? hundreds? thousands?) the former of which would be very vulnerable to malware. The other option is you get one certificate from some acceptable trusted CA, or maybe you just mint your own, and then use that everywhere. This destroys privacy since trackers can just correlate the presented certificate. There are also a whole bunch of environments where the secure web appears to work, but mutual authentication (the use of client certificates) does not work. In these environments the owner of the computers (which may not be the user) has authorised a middlebox HTTPS proxy. You can't do this with mutual authentication, you can find companies that are sure they have a solution, unless payment is conditional on the solution working rather than just being promised - at which point they'll remember they can't do it. The reason this can't work is that TLS allows both parties to detect who they're talking to with mutual authentication, whereas in the usual single auth case only the client knows there is a middlebox. So to work around this you'd be reconfiguring Google's servers (as an example), not your computers, and unsurprisingly Google does not want that.
  - nybble41 6y ago
    > One option is each site you authenticate to needs to issue you a certificate for your identity on that site. … The other option is you get one certificate from some acceptable trusted CA, or maybe you just mint your own, and then use that everywhere. There is a third option: You keep a single master secret in the browser, and combine that with the identity of the site (e.g. the domain name) via a secure trapdoor function to create a unique per-site key pair which is then used for public-key authentication with only that site. The site-specific secret is easily recreated from the master, but without the master secret there is no feasible way to correlate two site-specific identities. This is the approach used by modern (Hierarchical Deterministic) Bitcoin wallets. Older versions used distinct random private keys for every transaction, which as you say made key management rather painful. A single key which can be backed up once and used for any number of separate authentication channels is far more ergonomic. Middleboxes are indeed a major problem for TLS mutual authentication. IMHO this would be a good reason to favor TLS client certificates for popular web sites—perhaps we could finally get enough pressure to see these MitM-boxes booted off the network.
baybal2 6y ago
We have! Client certs been around since time immemorial.
- smitty1e 6y ago
  What hasn't happened that I've seen is anybody making the whole certificate system readily accessible to the non-specialist.
xondono 6y ago
I’m hoping that at some point in the future that’s what password managers will become, client certificate managers.
njsubedi 6y ago
When you are trying to login to iCloud or AppleID homepage from Safari on iOS, the OS asks you if you’d like to authenticate to the website using the iCloud account that is currently added on that device. So we have that tech, but I think the browser vendors need to do some work to support what you’re asking for.
Rafert 6y ago
WebAuthn does this pretty much.
throw0101a 6y ago
* https://en.wikipedia.org/wiki/WebAuthn https://en.wikipedia.org/wiki/WebAuthn Most of the current web browsers support it AFAICT: * https://caniuse.com/#search=webauthn https://caniuse.com/#search=webauthn * https://webauthn.io https://webauthn.io The upcoming Safari 14 will add further support: * https://www.theverge.com/2020/6/24/21301509/apple-safari-14-browser-face-touch-id-logins-webauthn-fido2 https://www.theverge.com/2020/6/24/21301509/apple-safari-14-...

As arpa mentioned in the other thread, client certificates are a thing. Outside of corporate infrastructure the implementation is somewhat painful though and OS/browser sides far from optimal in terms of user experience.

indigo945 6y ago
Yes, and browser vendors have refused to enhance support for this. To be fair though, client certificates have some obvious downsides, before all that you only have them on the device where they have been created. Since most people use several devices (desktop/notebook/tablet/phone) throughout the day, you require some way to keep them in sync. Cloud services could solve this, but tend to be vendor-specific, and doing it by hand via sneakernet is painful. Then this same problem occurs all over again if a certificate is leaked, for example due to device theft, and the cert needs to be revoked and replaced. In summary, while browser and mobile OS vendors could cooperate to improve the situation with client certificates, as of now, there appears to be no interest from any party to do so, and unless it happens, it is not worth it to use client certificates at all.
- nybble41 6y ago
  > Since most people use several devices (desktop/notebook/tablet/phone) throughout the day, you require some way to keep them in sync. The obvious solution, rather than syncing the certificates, would be to allow more than one client certificate per account. Each device would have its own certificate. If one device is compromised you need only revoke that particular certificate; other devices could still access the account. To avoid the need to manually register multiple certificates for each account you could cross-sign the per-device certificates; i.e. if key A is registered, and key B is signed by key A, then key B can also be used to sign in, perhaps with a warning sent to the owner of the account about a login from a new device.
tialaramex 6y ago
Cryptographic certificates bind a key to an identity. But, that's not really what we want in this scenario (notice how your SSH keys aren't bound to an identity) so immediately alarm bells should be going off. One option is each site you authenticate to needs to issue you a certificate for your identity on that site. Web browsers would presumably become responsible for minting the CSR during registration, and then hanging on to however many private keys and certificates (dozens? hundreds? thousands?) the former of which would be very vulnerable to malware. The other option is you get one certificate from some acceptable trusted CA, or maybe you just mint your own, and then use that everywhere. This destroys privacy since trackers can just correlate the presented certificate. There are also a whole bunch of environments where the secure web appears to work, but mutual authentication (the use of client certificates) does not work. In these environments the owner of the computers (which may not be the user) has authorised a middlebox HTTPS proxy. You can't do this with mutual authentication, you can find companies that are sure they have a solution, unless payment is conditional on the solution working rather than just being promised - at which point they'll remember they can't do it. The reason this can't work is that TLS allows both parties to detect who they're talking to with mutual authentication, whereas in the usual single auth case only the client knows there is a middlebox. So to work around this you'd be reconfiguring Google's servers (as an example), not your computers, and unsurprisingly Google does not want that.
- nybble41 6y ago
  > One option is each site you authenticate to needs to issue you a certificate for your identity on that site. … The other option is you get one certificate from some acceptable trusted CA, or maybe you just mint your own, and then use that everywhere. There is a third option: You keep a single master secret in the browser, and combine that with the identity of the site (e.g. the domain name) via a secure trapdoor function to create a unique per-site key pair which is then used for public-key authentication with only that site. The site-specific secret is easily recreated from the master, but without the master secret there is no feasible way to correlate two site-specific identities. This is the approach used by modern (Hierarchical Deterministic) Bitcoin wallets. Older versions used distinct random private keys for every transaction, which as you say made key management rather painful. A single key which can be backed up once and used for any number of separate authentication channels is far more ergonomic. Middleboxes are indeed a major problem for TLS mutual authentication. IMHO this would be a good reason to favor TLS client certificates for popular web sites—perhaps we could finally get enough pressure to see these MitM-boxes booted off the network.

baybal2 6y ago

We have! Client certs been around since time immemorial.

smitty1e 6y ago
What hasn't happened that I've seen is anybody making the whole certificate system readily accessible to the non-specialist.

xondono 6y ago

I’m hoping that at some point in the future that’s what password managers will become, client certificate managers.

njsubedi 6y ago

When you are trying to login to iCloud or AppleID homepage from Safari on iOS, the OS asks you if you’d like to authenticate to the website using the iCloud account that is currently added on that device. So we have that tech, but I think the browser vendors need to do some work to support what you’re asking for.

Rafert 6y ago

WebAuthn does this pretty much.

throw0101a 6y ago

* https://en.wikipedia.org/wiki/WebAuthn https://en.wikipedia.org/wiki/WebAuthn Most of the current web browsers support it AFAICT: * https://caniuse.com/#search=webauthn https://caniuse.com/#search=webauthn * https://webauthn.io https://webauthn.io The upcoming Safari 14 will add further support: * https://www.theverge.com/2020/6/24/21301509/apple-safari-14-browser-face-touch-id-logins-webauthn-fido2 https://www.theverge.com/2020/6/24/21301509/apple-safari-14-...