Security incident on Fedora infrastructure on 23 Jan 2011

[brett lentz]

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.