[Fedora-infrastructure-list] better passwords ,etc

[Patrick W. Barnes]

On Saturday 15 July 2006 21:34, Jeffrey Tadlock <linux at 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 at 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/
-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20060715/57e2b93b/attachment.bin