On 26/01/11 22:16, brett lentz wrote:
On Wed, Jan 26, 2011 at 1:44 PM, Athmane Madjoudj
> 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
>> 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
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
* 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
infrastructure mailing list
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.
Tristan Santore BSc MBCS
Network and Infrastructure Operations
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: