Password policy changes

Leslie S Satenstein lsatenstein at yahoo.com
Wed Mar 25 00:07:55 UTC 2015


Hi Adam
I am not aware of the distribution of Fedora users. I would suspect individuals comprise 90% and small business another 5% and others.
>From my business experience, we know about separation of duties. We assign one group to setup the hardware and install Linux, and the second group to receive a hand-over. In the handover process, root and admin passwords are changed.
What we practiced in the hardware/Software setup group, was to use the simplist of passwords. Yes, 123456, or Vancouver, (I went to UBC). I could see a single password rule as follows:

                        Anything goes.with the caveat

On first system logon, Root and adminstrator passwords must be replaced with ones respecting Fedora security rules. 

I fully agree with you, that the rules from anaconda, used for installing Fedora 21, were just fine. I am happy to return to them.
My workaround for the new rule(s) was to use #montreal001 as a password for both admin and root, with a change for each, following first boot.  

 
Regards 
 Leslie
 Mr. Leslie Satenstein
Montréal Québec, Canada


 
      From: Adam Williamson <adamwill at fedoraproject.org>
 To: server at lists.fedoraproject.org; desktop at lists.fedoraproject.org; kde at lists.fedoraproject.org; cloud at lists.fedoraproject.org 
 Sent: Tuesday, March 24, 2015 11:36 AM
 Subject: Password policy changes
   
Hey, folks. I'm writing with my Server SIG member hat on, here. We've 
been discussing password policy changes at our meeting today.

So the Great Password Policy Bunfight of 2015 was resolved by anaconda 
creating a mechanism for products/spins to set their own password 
policy:

https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc09c1c42e181

I'm slightly worried, however, about the possibility that everyone 
goes out and picks a more lenient policy more or less at random and we 
wind up with different policies on every Fedora medium. That seems 
like it'd be needlessly confusing to users and difficult to document.

I'm wondering if those products/spins intending to set a policy weaker 
than the default could all agree on the same one, so there'd only be 
at most two policies to care about (and if all products/spins overrode 
the upstream default, there'd only be one).

The obvious choice would be the pre-F22 policy, which I believe should 
be:

--nostrict --minlen=6 --minquality=50 --nochanges --emptyok

(though it's not *entirely* clear from the code - I think it used 
pwquality upstream defaults - so I may be a bit off).

What's the general feeling here? Have other SIGs discussed this yet? 
Come to any decisions? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
desktop mailing list
desktop at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150325/76be8245/attachment-0001.html>


More information about the server mailing list