10:02 a.m.
Given recent events in the linux-y world I think it might do us a
service to impose an ssh-key, user cert and password enforced change
flag day.
The idea would be everyone would be required to change their passwords,
ssh keys and any user certs they have before being allowed to do
anything else on our systems.
Anyone failing to change them would be locked out after a specific
date.
In particular I would like to make sure that ssh keys get changed - so
much so that I would want to keep a copy of the existing ssh keys and
verify that the new one does not match the old one before allowing it to
be used.
I'd like to discuss the efficacy and timing of this. If anyone has
perspective that is helpful, please share it.
I think this should be done soon, personally.
-sv
11:01 a.m.
I think a "security event driven" change policy would be more
effective than an arbitrary change policy driven by a deadline.
LinuxCode asked me about this in #fedora-noc after I mentioned:
"... there is conflicting evidence (one might call it 'opinion' more
than evidence) as to whether frequent changes are effective ... just a
thought"
The article that precipitated this comment was one published by Bruce
Schneier [0]. Again, this is "yet another opinion."
SOURCES:
[0] http://www.schneier.com/blog/archives/2010/11/changing_passwo.html
11:05 a.m.
On Mon, 2011-09-12 at 12:01 -0400, Adam M. Dutko wrote:
I think a "security event driven" change policy would be
more
effective than an arbitrary change policy driven by a deadline.
LinuxCode asked me about this in #fedora-noc after I mentioned:
"... there is conflicting evidence (one might call it 'opinion' more
than evidence) as to whether frequent changes are effective ... just a
thought"
The article that precipitated this comment was one published by Bruce
Schneier [0]. Again, this is "yet another opinion."
I'm not arguing about the efficacy of frequent changes. Nor am I
recommending we do it often. I'm saying right now, here, today, we force
a change.
Not once a month
Not once every 3 months
Not at any fixed schedule.
Not on a boat
Not with a goat.
-sv
11:40 a.m.
On Mon, 12 Sep 2011 11:02:01 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
Given recent events in the linux-y world I think it might do us a
service to impose an ssh-key, user cert and password enforced change
flag day.
The idea would be everyone would be required to change their
passwords, ssh keys and any user certs they have before being allowed
to do anything else on our systems.
Anyone failing to change them would be locked out after a specific
date.
In particular I would like to make sure that ssh keys get changed - so
much so that I would want to keep a copy of the existing ssh keys and
verify that the new one does not match the old one before allowing it
to be used.
I'd like to discuss the efficacy and timing of this. If anyone has
perspective that is helpful, please share it.
I think this should be done soon, personally.
Some random thoughts/considerations:
* We could also change fas password requirements at this time.
We have: https://fedorahosted.org/fedora-infrastructure/ticket/2804
where we agreed with:
- Nine or more characters with lower and upper case letters, digits and
punctuation marks.
- Ten or more characters with lower and upper case letters and digits.
- Twelve or more characters with lower case letters and digits.
* user certs and passwords are pretty quick and easy to change. Some
people may object to ssh keys being changed, so I think we need to
present clear reasoning on it. Perhaps:
"While your ssh private key is hopefully secure, we would like you to
take this chance to generate a new one and review your passphrase, key
size and type and consider a separate key for fedora access. In the
event your old private key was transferred or backed up to a system you
may no longer realize it's still stored on, a new private key will
allow you to confirm and review it's setup and storage."
* We may have some users who have email on the affected systems (ie,
kernel.org, linux.com, etc). Should we wait for those systems to be
back up before taking action? They should be able to login and change
their email in fas, but they may be unaware of the need to do so.
* For timing, we want to make sure this won't affect maintainers too
much working on the release. Perhaps the deadline should be F16
release? or is that too far out?
* We could also be more strict with all users in the 'sysadmin*'
groups perhaps. Ie, a shorter timeline for them to change things. Or
make them the only group thats required to change and just suggest to
other groups they do so.
* Users who fail to meet the deadline would be marked 'inactive' ? What
would they need to do to re-activate? Just login and upload a new
key/change password?
* How many users do we have with ssh keys uploaded?
kevin
11:49 a.m.
On Mon, 2011-09-12 at 10:40 -0600, Kevin Fenzi wrote:
Some random thoughts/considerations:
* We could also change fas password requirements at this time.
We have: https://fedorahosted.org/fedora-infrastructure/ticket/2804
where we agreed with:
- Nine or more characters with lower and upper case letters, digits and
punctuation marks.
- Ten or more characters with lower and upper case letters and digits.
- Twelve or more characters with lower case letters and digits.
So - I am sure I'm not the only one who does this - but how about
mandating pass PHRASES and make the minimum length be 40 characters?
Mary_had_a_little_lamb_whose_fleece_was_white_as_snow would work just
fine and should be substantially harder to crack :)
(/me is all about making friends today, apparently)
* user certs and passwords are pretty quick and easy to change. Some
people may object to ssh keys being changed, so I think we need to
present clear reasoning on it. Perhaps:
"While your ssh private key is hopefully secure, we would like you to
take this chance to generate a new one and review your passphrase, key
size and type and consider a separate key for fedora access. In the
event your old private key was transferred or backed up to a system you
may no longer realize it's still stored on, a new private key will
allow you to confirm and review it's setup and storage."
* We may have some users who have email on the affected systems (ie,
kernel.org, linux.com, etc). Should we wait for those systems to be
back up before taking action? They should be able to login and change
their email in fas, but they may be unaware of the need to do so.
This sounds reasonable - though perhaps we should isolate that set of
users now and give their accounts an extra scouring. :)
* For timing, we want to make sure this won't affect maintainers
too
much working on the release. Perhaps the deadline should be F16
release? or is that too far out?
I'd be inclined for sooner than later but <shrug>
* We could also be more strict with all users in the 'sysadmin*'
groups perhaps. Ie, a shorter timeline for them to change things. Or
make them the only group thats required to change and just suggest to
other groups they do so.
This sounds good.
* Users who fail to meet the deadline would be marked
'inactive' ? What
would they need to do to re-activate? Just login and upload a new
key/change password?
well "login" might be hard. I suspect we just nuke their ssh keys so
they cannot login to any shell w/o first getting into the fas.
* How many users do we have with ssh keys uploaded?
3728 users on fedorapeople.org
That's fpca + 1 group.
1776 on fedorahosted.org - I've not checked for overlap there,
obviously.
-sv
5:35 p.m.
On Mon, Sep 12, 2011 at 10:49, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Mon, 2011-09-12 at 10:40 -0600, Kevin Fenzi wrote:
> Some random thoughts/considerations:
>
> * We could also change fas password requirements at this time.
> We have: https://fedorahosted.org/fedora-infrastructure/ticket/2804
> where we agreed with:
>
> - Nine or more characters with lower and upper case letters, digits and
> punctuation marks.
>
> - Ten or more characters with lower and upper case letters and digits.
>
> - Twelve or more characters with lower case letters and digits.
So - I am sure I'm not the only one who does this - but how about
mandating pass PHRASES and make the minimum length be 40 characters?
Mary_had_a_little_lamb_whose_fleece_was_white_as_snow would work just
fine and should be substantially harder to crack :)
(/me is all about making friends today, apparently)
My only issue with that is making sure that the hashing method allows
for it. Finding out that it stops at 16 characters for some reason
means a lot of wasted typing. In the end, I would say that having to
type in 40 characters every time my window times out on Fedora
Community or admin would make me grumpy after the 4th login in a day.
> * Users who fail to meet the deadline would be marked 'inactive' ? What
> would they need to do to re-activate? Just login and upload a new
> key/change password?
well "login" might be hard. I suspect we just nuke their ssh keys so
they cannot login to any shell w/o first getting into the fas.
Agreed.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
2:18 p.m.
On Monday, September 12, 2011 10:02:01 AM seth vidal wrote:
The idea would be everyone would be required to change their
passwords,
ssh keys and any user certs they have before being allowed to do
anything else on our systems.
i honestly am ok with not forcing user cert changes, only because we expire
all user certs every 6 months already. all users get new keys and certs twice
a year. but passwords and ssh keys im not against.
i currently use a 4096 bit rsa key maybe we should add a check to force at
least a 2048 bit key
Dennis
4608
days inactive
4608
days old
infrastructure@lists.fedoraproject.org
6 comments
5 participants
participants (5)
-
Adam M. Dutko -
Dennis Gilmore -
Kevin Fenzi -
Seth Vidal -
Stephen John Smoogen