5 ms·

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. T

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate. On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

shreddit 1y ago
Unfortunately the tech community is full of people who pride themselves on speaking for everyone and telling everyone to stop having fun with new tech because their solution is the best. And the one only truth.
yomismoaqui 1y ago
All developers pass this magpie phase [1] and as you get older you start to see new things more critically. I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech. [1]: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/
- skybrian 1y ago
  I’ll add that eventually it’s less about what I want and more about what would work for other people I know. Many of them aren’t very technical. What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?
- palata 1y ago
  Are you trying to say that security keys are not a good thing? I love security keys, that's my one example of a good technology.
deleted 1y ago
[deleted]
vbezhenar 1y ago
ssh is terribly insecure with no way of checking server certificate fingerprint automatically. Web solved it decades ago with CA.
- karmarepellent 1y ago
  This is incorrect. SSH certificates work just like x509 certificates in that regard. Also, with PubkeyAuthentication, there exist all kinds of ways to collect host keys before connecting to them for the first time and thus avoiding the trust-on-first-use problem. Especially in private networks where you control all the nodes.
  - palata 1y ago
    SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints. Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).
    - tptacek 1y ago
      If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?
      - palata 1y ago
        I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.
        tptacek 1y ago
        SSH has always relied on key continuity for this problem; you're exposed when you're first introduced to a host (on a particular client) but then fine from that point on. This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.
karmarepellent 1y ago
> Signing in is cryptographically signing a commitment to the current ephemeral tunnel. I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding? Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service). I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.
- alphazard 1y ago
  > authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding? No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party. > let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service) This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.
  - palata 1y ago
    The thing is, if you want to use SSH with a secure element, suddenly you're using FIDO2, right? OpenSSH already supports it. And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.
    - NoGravitas 1y ago
      It's the stuff it adds that most people object to.
      - 1y ago
01HNNWZ0MV43FF 1y ago
> Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel. How do I sign in from multiple computers?
- karmarepellent 1y ago
  A service that lets you sign up by uploading a SSH public key could just as well let you upload multiple public keys in your profile to be able to connect from other devices.
  - tadfisher 1y ago
    Amazing, just like passkeys!
    - karmarepellent 1y ago
      The sarcasm is duly noted. But I simply answered the question. I don't have any strong opinion regarding passkeys.
      - deleted 1y ago
        [deleted]
    - Nextgrid 1y ago
      Biggest difference is that SSH keys allow you to store and submit the public key without the private key being present. With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment. This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).
agwa 1y ago
The simplicity of SSH's public key authentication comes with a significant privacy downside: https://www.agwa.name/blog/post/whoarethey https://www.agwa.name/blog/post/whoarethey https://words.filippo.io/whoami-updated/ https://words.filippo.io/whoami-updated/ This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.
- alphazard 1y ago
  The complexity is unwarranted. The only thing that needs standardizing is how to hand over public keys (SSH format works fine), and what to sign to prove identity. Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.
- NoGravitas 1y ago
  Use a different public key for every site, specify which one in your .ssh/config. Only offer keys for the site(s) they correspond to. Done. This is already best practice, but could easily be improved by simple tools to manage it. You do not also need things like attestation and restriction of backups.
adiabatichottub 1y ago
@alphazard, what are your thoughts on using self-signed X.509 certs, since 95% of the infrastructure is already there?
- alphazard 1y ago
  I'm opposed to using certs where public keys will do. Certificates especially X.509 are more complicated than the public keys that they reference. They include things like domain names, serial numbers, version numbers, etc. The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us. The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.
  - adiabatichottub 1y ago
    Yes, I agree much of the added complexity isn't necessary, but since TLS is a common and widely used protocol for just about everything other than SSH, it seems like it would be easier to plug in. Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?
  - kbolino 1y ago
    DNS for key management is nonviable due to the lack of uptake of DNSSEC. Though it's an interesting hypothetical question whether that would still have been the case without X.509.
palata 1y ago
> On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)
- AnnualDegree99 1y ago
  I use this very setup, it works great. Yubikey has supported resident keys for a while.
turtlebits 1y ago
"Solved" doesn't mean anything unless you have implementation/adoption.
- palata 1y ago
  And it's just not true: ever wondered what those fingerprints are that nobody cares about and blindly goes for "yes" in SSH? The vast majority of SSH users would have no idea if they got MitM-ed. WebAuthn helps prevent just that.
  - dandanua 1y ago
    WebAuthn won't help you if you are signing-up on a phishing site.
    - palata 1y ago
      Well if you sign up on a phishing site, they won't be able to access the legit site with your credentials...
      - dandanua 1y ago
        Niеther an ssh MITM can use your private key on a legit server. A middleman doesn't need it in most cases, however. My point was that the situation with ssh is basically the same as with webauthn.
        palata 1y ago
        > Niеther an ssh MITM can use your private key on a legit server Of course they can: that's precisely the meaning of MITM. They don't get direct access to your private key (because they wouldn't need to stay in the middle anymore at that point), but they will ask you to sign the challenge sent by the legit server, which you will happily do if you don't realise that you are not talking to the legit server. WebAuthn prevents that MitM part.

shreddit 1y ago

Unfortunately the tech community is full of people who pride themselves on speaking for everyone and telling everyone to stop having fun with new tech because their solution is the best. And the one only truth.

yomismoaqui 1y ago

All developers pass this magpie phase [1] and as you get older you start to see new things more critically. I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech. [1]: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/

skybrian 1y ago
I’ll add that eventually it’s less about what I want and more about what would work for other people I know. Many of them aren’t very technical. What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?
palata 1y ago
Are you trying to say that security keys are not a good thing? I love security keys, that's my one example of a good technology.

deleted 1y ago

[deleted]

vbezhenar 1y ago

ssh is terribly insecure with no way of checking server certificate fingerprint automatically. Web solved it decades ago with CA.

karmarepellent 1y ago
This is incorrect. SSH certificates work just like x509 certificates in that regard. Also, with PubkeyAuthentication, there exist all kinds of ways to collect host keys before connecting to them for the first time and thus avoiding the trust-on-first-use problem. Especially in private networks where you control all the nodes.
- palata 1y ago
  SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints. Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).
  - tptacek 1y ago
    If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?
    - palata 1y ago
      I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.
      - tptacek 1y ago
        SSH has always relied on key continuity for this problem; you're exposed when you're first introduced to a host (on a particular client) but then fine from that point on. This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.

karmarepellent 1y ago

> Signing in is cryptographically signing a commitment to the current ephemeral tunnel. I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding? Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service). I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.

alphazard 1y ago
> authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding? No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party. > let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service) This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.
- palata 1y ago
  The thing is, if you want to use SSH with a secure element, suddenly you're using FIDO2, right? OpenSSH already supports it. And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.
  - NoGravitas 1y ago
    It's the stuff it adds that most people object to.
    - 1y ago

01HNNWZ0MV43FF 1y ago

> Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel. How do I sign in from multiple computers?

karmarepellent 1y ago
A service that lets you sign up by uploading a SSH public key could just as well let you upload multiple public keys in your profile to be able to connect from other devices.
- tadfisher 1y ago
  Amazing, just like passkeys!
  - karmarepellent 1y ago
    The sarcasm is duly noted. But I simply answered the question. I don't have any strong opinion regarding passkeys.
    - deleted 1y ago
      [deleted]
  - Nextgrid 1y ago
    Biggest difference is that SSH keys allow you to store and submit the public key without the private key being present. With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment. This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).

agwa 1y ago

The simplicity of SSH's public key authentication comes with a significant privacy downside: https://www.agwa.name/blog/post/whoarethey https://www.agwa.name/blog/post/whoarethey https://words.filippo.io/whoami-updated/ https://words.filippo.io/whoami-updated/ This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.

alphazard 1y ago
The complexity is unwarranted. The only thing that needs standardizing is how to hand over public keys (SSH format works fine), and what to sign to prove identity. Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.
NoGravitas 1y ago
Use a different public key for every site, specify which one in your .ssh/config. Only offer keys for the site(s) they correspond to. Done. This is already best practice, but could easily be improved by simple tools to manage it. You do not also need things like attestation and restriction of backups.

adiabatichottub 1y ago

@alphazard, what are your thoughts on using self-signed X.509 certs, since 95% of the infrastructure is already there?

alphazard 1y ago
I'm opposed to using certs where public keys will do. Certificates especially X.509 are more complicated than the public keys that they reference. They include things like domain names, serial numbers, version numbers, etc. The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us. The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.
- adiabatichottub 1y ago
  Yes, I agree much of the added complexity isn't necessary, but since TLS is a common and widely used protocol for just about everything other than SSH, it seems like it would be easier to plug in. Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?
- kbolino 1y ago
  DNS for key management is nonviable due to the lack of uptake of DNSSEC. Though it's an interesting hypothetical question whether that would still have been the case without X.509.

palata 1y ago

> On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)

AnnualDegree99 1y ago
I use this very setup, it works great. Yubikey has supported resident keys for a while.

turtlebits 1y ago

"Solved" doesn't mean anything unless you have implementation/adoption.

palata 1y ago
And it's just not true: ever wondered what those fingerprints are that nobody cares about and blindly goes for "yes" in SSH? The vast majority of SSH users would have no idea if they got MitM-ed. WebAuthn helps prevent just that.
- dandanua 1y ago
  WebAuthn won't help you if you are signing-up on a phishing site.
  - palata 1y ago
    Well if you sign up on a phishing site, they won't be able to access the legit site with your credentials...
    - dandanua 1y ago
      Niеther an ssh MITM can use your private key on a legit server. A middleman doesn't need it in most cases, however. My point was that the situation with ssh is basically the same as with webauthn.
      - palata 1y ago
        > Niеther an ssh MITM can use your private key on a legit server Of course they can: that's precisely the meaning of MITM. They don't get direct access to your private key (because they wouldn't need to stay in the middle anymore at that point), but they will ask you to sign the challenge sent by the legit server, which you will happily do if you don't realise that you are not talking to the legit server. WebAuthn prevents that MitM part.