4 ms·

You may be interested in knowing that you can DOS someone if you know only their public keys. https://medium.com/@gmalette/mistaking-authentication-for-identifi

You may be interested in knowing that you can DOS someone if you know only their public keys. https://medium.com/@gmalette/mistaking-authentication-for-identification-983447739eee https://medium.com/@gmalette/mistaking-authentication-for-id...

marcosdumay 11y ago
You can DOS anyone at any time, just by knowing how to contact them. DOS is the one attack one can not defend against, only attenuate.
- eru 11y ago
  A DOS is especially annoying, if the attacker needs to burn less resources than the defender.
barkingcat 11y ago
You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace. Public keys are supposed to be public.
- gmalette 11y ago
  I'm not arguing they're not, but that they shouldn't be used as a means of identification
eridius 11y ago
DOS is a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway. > A simple solution would be to avoid the single user login git@service.com, and use that as identification, for example gmalette@service.com. Except this completely ignores the reason why services use git@service.com. It's not because they're lazy. It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server), and removes the ability for people to copy&paste a `git clone` command from a README (or blog post or wherever else). So yes, there is a theoretical annoyance attack here, but nobody really cares because it's never going to happen accidentally, it can't be used against most people, and it's so trivially bypassed nobody's going to bother doing it except as a PoC. The benefits of using git@service.com greatly outweigh the downsides.
- gmalette 11y ago
  > and it's easily solved by a small SSH config change on their end The article does mention it. The issue is not fixing the problem, it's actually finding it. > [...] that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server) It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku? For Github et. al, that's easily solved by project-level or organization-level identity. > that URL wouldn't work for anyone else And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host. > nobody really cares because it's never going to happen accidentally Except it does. Those service providers often get contacted because this happens BY ACCIDENT. I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config. A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account. I've heard similar stories elsewhere too.
  - eridius 11y ago
    > It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku? I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you. > For Github et. al, that's easily solved by project-level or organization-level identity. How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@. > And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host. Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way. > Those service providers often get contacted because this happens BY ACCIDENT. Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this. > A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account. Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.

marcosdumay 11y ago

You can DOS anyone at any time, just by knowing how to contact them. DOS is the one attack one can not defend against, only attenuate.

eru 11y ago
A DOS is especially annoying, if the attacker needs to burn less resources than the defender.

barkingcat 11y ago

You can dos someone just by knowing their ip or how to get a hold of them. You can also sign up magazines to be delivered to their office address and DOS their workplace. Public keys are supposed to be public.

gmalette 11y ago
I'm not arguing they're not, but that they shouldn't be used as a means of identification

eridius 11y ago

DOS is a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway. > A simple solution would be to avoid the single user login git@service.com, and use that as identification, for example gmalette@service.com. Except this completely ignores the reason why services use git@service.com. It's not because they're lazy. It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server), and removes the ability for people to copy&paste a `git clone` command from a README (or blog post or wherever else). So yes, there is a theoretical annoyance attack here, but nobody really cares because it's never going to happen accidentally, it can't be used against most people, and it's so trivially bypassed nobody's going to bother doing it except as a PoC. The benefits of using git@service.com greatly outweigh the downsides.

gmalette 11y ago
> and it's easily solved by a small SSH config change on their end The article does mention it. The issue is not fixing the problem, it's actually finding it. > [...] that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server) It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku? For Github et. al, that's easily solved by project-level or organization-level identity. > that URL wouldn't work for anyone else And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host. > nobody really cares because it's never going to happen accidentally Except it does. Those service providers often get contacted because this happens BY ACCIDENT. I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config. A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account. I've heard similar stories elsewhere too.
- eridius 11y ago
  > It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku? I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you. > For Github et. al, that's easily solved by project-level or organization-level identity. How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@. > And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host. Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way. > Those service providers often get contacted because this happens BY ACCIDENT. Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this. > A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account. Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.