4 ms·

Care to share any specific advantages, aside from the general notion of “appropriate security”?

tialaramex 6y ago
SSH authentication is a public key authentication so: The relying party (GitHub in this case) learn nothing secret. Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. A MITM learns nothing secret. If things go wrong and you somehow allow a MITM attack to occur, the MITM doesn't get durable credentials from you, once you are talking to GitHub not the MITM they're locked out, even though they watched you authenticate successfully, perhaps many times, they do not learn how to forge working credentials.
- strogonoff 6y ago
  Thanks for elaborating. > If things go wrong and you somehow allow a MITM attack to occur I get the point, though perhaps the phrasing could do with a little less victim-shaming. How many of the times you were MITMed did you allow that to happen? Now count cases about which you still don’t know. > Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. To me, secret management on the side of an unsophisticated user is arguably of more worry than someone breaking into GitHub and stealing PATs. Consider if a user is casually contributing to documentation on GitHub using some Git client which forces them to supply an SSH key for authentication. Now there is more than one way things could go wrong, for example: 1) They use a key without a passphrase, and it is stored somewhere on their filesystem (perhaps under ~/.ssh, where ssh-keygen wants to place it by default) where any app with disk access can read it. Voila, a third party gets full access to their GitHub repositories. 2) They use a weak passphrase, reuse an old password for passphrase, or store the passphrase in plain text. Similar liability. Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). That said, a well-behaved user-friendly Git client could neutralize some of the downsides by taking care of generating a completely new, passphrase-protected SSH keypair under the hood, storing the passphrase and the private part reliably, and asking the user to add the public part to their GitHub account, each time it is set up on a new machine. I wonder how many clients go to such lengths.
  - tialaramex 6y ago
    > Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). Right, so, with a lot of extra hoop jumping GitHub have been able to special case HTTPS authentication for their site so that if you use these tokens it's only somewhat worse than what you get out of the box with SSH.

SSH authentication is a public key authentication so: The relying party (GitHub in this case) learn nothing secret. Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. A MITM learns nothing secret. If things go wrong and you somehow allow a MITM attack to occur, the MITM doesn't get durable credentials from you, once you are talking to GitHub not the MITM they're locked out, even though they watched you authenticate successfully, perhaps many times, they do not learn how to forge working credentials.

strogonoff 6y ago
Thanks for elaborating. > If things go wrong and you somehow allow a MITM attack to occur I get the point, though perhaps the phrasing could do with a little less victim-shaming. How many of the times you were MITMed did you allow that to happen? Now count cases about which you still don’t know. > Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. To me, secret management on the side of an unsophisticated user is arguably of more worry than someone breaking into GitHub and stealing PATs. Consider if a user is casually contributing to documentation on GitHub using some Git client which forces them to supply an SSH key for authentication. Now there is more than one way things could go wrong, for example: 1) They use a key without a passphrase, and it is stored somewhere on their filesystem (perhaps under ~/.ssh, where ssh-keygen wants to place it by default) where any app with disk access can read it. Voila, a third party gets full access to their GitHub repositories. 2) They use a weak passphrase, reuse an old password for passphrase, or store the passphrase in plain text. Similar liability. Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). That said, a well-behaved user-friendly Git client could neutralize some of the downsides by taking care of generating a completely new, passphrase-protected SSH keypair under the hood, storing the passphrase and the private part reliably, and asking the user to add the public part to their GitHub account, each time it is set up on a new machine. I wonder how many clients go to such lengths.
- tialaramex 6y ago
  > Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). Right, so, with a lot of extra hoop jumping GitHub have been able to special case HTTPS authentication for their site so that if you use these tokens it's only somewhat worse than what you get out of the box with SSH.