On Wed, 2011-10-12 at 12:48 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 21:38 +0200, Henrik Nordström wrote:
> ons 2011-10-12 klockan 12:20 -0700 skrev Adam Williamson:
>
> > Sure there is. There's the exact same problem as using the same password
> > across multiple projects: if someone compromises the key they have
> > compromised all of those projects. If you use a different key for each
> > project, an attacker can only compromise one project with any given key.
>
> To compromise my SSH key they need to compromise the location where my
> key is stored and the key encryption passprase.
Sure. However, if you have multiple keys with multiple passphrases, then
it's extra work to compromise each key. It is also possible, if you use
multiple keys for multiple systems, that you do not need to store every
key you own on every system you use. To take the possible real-world
example I raised...
let's say you have an account on
kernel.org and one on
linux.com. It may
make some kind of sense to your workflow for you to keep the private key
you use to access
linux.com in your home directory on
kernel.org.
No it doesn't make sense in *any* case.
Use ssh agent forwarding if you must.
Now,
if the key in question is 'your single personal key you use for
everything', then if someone compromises
kernel.org and then compromises
the key you have stored there, they have now compromised everything you
have access to, as you use that single key for everything.
You failed when you copied your private key on a shared system. End of
the game, no need to elaborate further
Plus if you do that changing keys will make hardly a difference, you
have bad behavior and you will expose your keys again, as I said before.
So you are only punishing those that are carefully by asking
indiscriminate ssh key changes.
Say the key in question is 'the key you use specifically for
linux.com',
and you didn't choose to store any other of your private keys on
kernel.org because you'd never need to access any other systems from
kernel.org, you have now successfully mitigated the scope of the attack
to
kernel.org and
linux.com but _not_ any of the other systems you have
access to (and use different keys for, keys which you did not store on
kernel.org).
Say you like to store you FAS password in a txt file unencrypted on
kernel.org, no need to steal keys, the attacker can simply load a new
key in FAS and have all access he needs.
If you have poor security policies for your security stuff you will
always endanger the systems you use, no matter how many times said
system forces you to change credentials. you will never force changing
credentials often enough to make a difference.
Simo.
--
Simo Sorce * Red Hat, Inc * New York