On Saturday 15 July 2006 21:34, Jeffrey Tadlock <linux(a)elfshadow.net> wrote:
Mike McGrath wrote:
> We'll have to find the balance. We could go key
>
> kerberos crazy if we wanted to. On the one hand we should have a
> very secure system. On the other hand we cannot burden the
> developers. After all thats the whole reason our team exists... to
> aid the developers.
There is definitely a balance to be struck. Keep the systems usable
while at the same time secure. The sysadmin's conundrum, eh?
SSH keys shouldn't be a big deal to developers though right?
As far as the web passwords, we obviously can't do away with those, that
crosses the usability line. But maybe there needs to be a check in
place before the ssh keys are pushed across systems? Not sure how that
check would work without adding overhead though.
I'm sure that many of us would probably be more tolerant of security
restrictions than other developers might be, so we'll have to be careful.
Something to consider for web authentication would be SSL client certificates
combined with passwords. It would be an additional barrier, but it would be
widely supported and shouldn't be too hard to enable in key places. I'm
concerned that it would be going too far, but I wanted to throw the idea
out. :-)
Other things to consider are simple rules, like timed lockouts after repeated
auth failures, password strength or expiry requirements, hostmask filters,
two-factor auth, strategic interface design, etc.
One thing I most recently noticed was that you need only an account name to
request a password reset URL be emailed. We could require two pieces of
information for verification. It doesn't add much security, but might
prevent some man-in-the-middle attacks and could reduce spam like many of our
contributors recently experienced.
In either case, finding potential pitfalls as these are part of
determining the balance. At least knowing where the weaker points of
the system are will allow us as a group to decide the acceptabilty of
that risk. An audit such as I suggest should help us find our weaker
spots along the way so we can at least discuss them and weigh risks
versus benefits.
The best practices portion are often times changes that few would notice
but could reduce our attack vector with no real penalty. Take a peek a
the sshd_config on bastion sometime. I was a little surprised. I had
assumed that host was only accepting ssh keys. Hardening ssh on that
machine wouldn't affect many people at all and we would still see some
potential gains from it.
I had actually spoken with Elliot briefly about this before the Infrastructure
team was put together. He had reasons to keep the systems allowing
passwords. I'll wait for him to chime in on this thread with any reasons
that are still blockers.
> It should also be said that I've never actually worked at a place
> that would end up on Slashdot if we got hacked.... I guess there's a
> bit of pride in me that wants to make sure that if the Fedora
> infrastructure ever does get hacked that it doesn't happen on my
> watch
Agreed!! :)
+1
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
http://www.n-man.com/
LinkedIn:
http://www.linkedin.com/in/nman64
Have I been helpful? Rate my assistance!
http://rate.affero.net/nman64/
--