On 26/01/11 22:16, brett lentz wrote: > On Wed, Jan 26, 2011 at 1:44 PM, Athmane Madjoudj <athmanem@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxx _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
