Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

[Simo Sorce]

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