Security incident on Fedora infrastructure on 23 Jan 2011

[Tristan Santore]

On 26/01/11 22:16, brett lentz wrote:
> On Wed, Jan 26, 2011 at 1:44 PM, Athmane Madjoudj <athmanem at gmail.com> wrote:
>> On 01/26/2011 06:51 PM, Ricky Zhou wrote:
>>> On 2011-01-25 01:24:54 PM, Jose Manimala wrote:
>>>> One question is should a password length and secure password creation
>>>> check be enforced on the FAS system. Like regular expression checks
>>>> and stuff. I know this is asking a lot, the current implementation
>>>> allows me to have a simple password if I remember(need to check) been
>>>> long. And password expiry?  :)
>>> Good point, password complexity checks are still listed as a TODO in
>>> FAS (although we do have a minimum length of 8 implemented), looks like
>>> we just never got to doing it.  I've added a note about those in
>>> https://fedorahosted.org/fedora-infrastructure/ticket/2574,
>>> which we will discuss in the next infra meeting.
>>>
>>
>> Maybe we should add a captcha after three (3) failed login attempts ?
>>
>> Sign up page already has a captcha
>>
>>
>> --
>> Athmane Madjoudj
> 
> I'm a big fan of eliminating passwords as an authentication option
> altogether. Though, that's likely to be impractical as a global policy
> change.
> 
> Here's some other ideas that I don't think have been mentioned (on list):
> 
> * Tracking unique source IPs of logins, and sending an e-mail to the
> account owner's e-mail address when we detect a login from a
> new/unknown IP source. This doesn't solve anything, but may reduce the
> time between compromise and notifying someone that there's a problem.
> 
> * Allow users to establish a white list of allowed source IPs for
> their login. This will add an additional set of requirements an
> attacker needs to compromise an account.
> 
> However, this would potentially create some chicken-and-egg problems,
> which would increase support costs when users lock themselves out of
> their account. It would likely also require additional logic to deal
> with potential logistical issues related to conventions and other
> travel.
> 
> * Allow users to disable the use of password auth on their account if
> they have an alternative method configured (e.g. yubikey).
> 
> * Password expiration and forced rotation. The typical, "rotate every
> M days, and the new password can't be any of your last N number of
> passwords," policy will at least keep the window for compromise a
> moving target.
> 
> 
> 
> ---Brett.
> _______________________________________________
> infrastructure mailing list
> infrastructure at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Passwords are not the issue. We have got yubikey support, and for a good
authentication mechanism, you need a multi-factor authentication
mechanism, be it two factor or three factor (probably too hard for our
purpose). Two-factor involves something somebody holds, that is a
password, and something somebody has, hardware authentication token
(yubikey). The GnuPG smart cards, which the FSF also uses, provide this
all in one, including a self-destruct option, so nobody who has the
card, can keep guessing the password.
Maybe if we can, we should implement a password + yubikey option and
introduce a password lock, if more than 20 auths have happened, on a
yubikey+password enabled account.

Just using the yubikey itself is dangerous. Which , although I own a few
yubikeys, do not use for FI/People.

Regards,

Tristan

-- 
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore at internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore at fedoraproject.org