FESCO request to revert password confirmation change in F22

[Adam Jackson]

As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that
anaconda revert a password behaviour change in the UI from F22,
restoring the "double-click to confirm weak password" behaviour from F21
and earlier.

As for how that's realized: I'm not picky. If it makes more sense from
a development or maintenance perspective to keep the revert in fedora
package git rather than rhinstaller upstream, that's fine; if it makes
more sense to revert upstream as well, that's fine too.

FESCO is prepared to work with anaconda and other stakeholders to define
security models for the various Fedora products. By clarifying our
needs we hope to avoid this kind of contention in the future.

For FESCO,

- ajax

[David Cantrell]

Post by Adam Jackson
As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that
anaconda revert a password behaviour change in the UI from F22,
restoring the "double-click to confirm weak password" behaviour from F21
and earlier.
From what I'm reading in the meeting logs and the ticket comments, it

appears the revert decision is basically a temporary solution and a more
formal security policy will be discussed later. We had technical arguments
in favor of the change originally, but I have yet to see technical arguments
against the change come together in any sort of concrete policy.

I wish a formal distribution and/or per-variant security policy would come
from FESCo (or a committee directed by FESCo) so we could resolve the
concerns now and going forward. I don't see the revert decision as being a
good step in that direction, only because there was really no technical
discussion or reasoning around it.

Post by Adam Jackson
As for how that's realized: I'm not picky. If it makes more sense from
a development or maintenance perspective to keep the revert in fedora
package git rather than rhinstaller upstream, that's fine; if it makes
more sense to revert upstream as well, that's fine too.

Without an official policy on the matter and only a temporary solution for
now, upstream won't be changing. Fedora will need to carry this deviation
as a patch in package git for F-22.

Post by Adam Jackson
FESCO is prepared to work with anaconda and other stakeholders to define
security models for the various Fedora products. By clarifying our
needs we hope to avoid this kind of contention in the future.

The discussion for this might as well start now -or- at least early enough
so it's not too late for F-23.

Thanks,

[Adam Jackson]

Post by David Cantrell
I wish a formal distribution and/or per-variant security policy would come
from FESCo (or a committee directed by FESCo) so we could resolve the
concerns now and going forward. I don't see the revert decision as being a
good step in that direction, only because there was really no technical
discussion or reasoning around it.

Speaking only for myself: yeah, I didn't like it either. I voted
against it (asking for a revert) in the 28 February meeting because I
was hoping the engineering teams actually involved would be willing to
work with each other. That appears not to have happened, which I
consider deeply disappointing all around.

There wasn't _no_ technical discussion. Plenty of people were willing
to point out that pwquality being overzealous was making it reject
passwords that would otherwise have passed on F21, or would be expected
to be "sufficiently strong" according to whatever metric. Plenty of
people were willing to point out the ways policy might vary here
depending on the deployment scenario.

But nobody was willing to make those ideas manifest in, you know, code.

So the technical consideration (I felt) we were left with was not
"regressing" relative to F21. That is a stunningly weak justification,
given that what we're regressing from wasn't especially well-defined and
that we change plenty of things in every release, but here we are.

Post by David Cantrell

Post by Adam Jackson
FESCO is prepared to work with anaconda and other stakeholders to define
security models for the various Fedora products. By clarifying our
needs we hope to avoid this kind of contention in the future.

The discussion for this might as well start now -or- at least early enough
so it's not too late for F-23.

Indeed. I'll bring this back to fesco to find someone to head this up.

- ajax

[Leslie S Satenstein]

Hi Adam
Thank you for your comments. Here are mine.

In large shops (1500+ employees), a Linux-network techie is given the task of installing and testing a server. He sets it up, he insures it is up to date, and when he has completed his Q/A, he turns the system over to operations or chief System Administrator. Operations will immediately change passwords, and begin the "PiP"  Placing into Production.

Before Fedora21, I would insist on the techie using a very simple password and follow up, post reboot with a stronger one. And again, another PW change for PiP. Passwords are changed with each handover.   

I was against the new enforcement .I had some experience with anaconda failing me when I chose the French keyboard layout for the installation. The password letters I chose using my French selection, did not exist on the US layout. On reboot, I could not get into root. Lots of lost time to work around. That alone is justification for a kiss approach.

If "ABC123abc$$$ works anaconda, we can all just use it or similar one that meets the rules. Rest assured, every first install or test install of a new Fedora or Centos will have root set with that fixed value, and a new password presented on first reboot.  

Regards
 Leslie
grandfather Leslie, 55 yrs in IT.

[Leslie S Satenstein]

Hi David
I am a Fedora end-user. After 55 years in IT in the largest of the large institutions (350,000 employees) and the smallest of going concerns 10 employees) as Mr Security, Mr Performance, Mr Capacity Planner, Mr Manager, Mr Owner, etc., I am in semi-retirement and I would like to briefly present my comments about password management.
People will get over the new password rule. There is no need to revert back.

I tested with the new rules.  I chose "#montreal001#montreal001".  From now on, I will use that passowrd for all my anaconda installations. I point out this decision for one reason.
In medium and large shops alike, most often a new Linux installation is given to junior technical staff to build. He is told to use a specific password and to advise the "head system administrator" as to when the system is ready for PiP (Placing/Turnover/Handover to Production).   The system builder may be in a remote location, time-zones away from head-office.

The hand-over to the system-administrator includes a mandatory password change for root and for the enrolment administrator.

After first boot, all user accounts are set up to force a password  change on a user's first login attempt. That rule is practised, strictly enforced and is a default in 99.999% of all shops. 

So, with anaconda, it matters not if the password is abc or #montreal001#montreal001. I force the users to change his/her password on their first login attempt.

As a reminder, with the  system "passwd" command, root can force any password to be accepted. And that option is a work-around to what was implemented within anaconda.
If you want to enforce better security, set-up anacondao to create root and administrator passwords that must be changed on first system login. 
There is a second reason why I defer the real password to first reboot.  I enable ±, @ £ ¢ ¬ € Â¥ ÂŒ % Âœ Ÿ to be part of the new password.

The annoyance about having to type a few extra letters will pass. I find no reason to revert this part of the anaconda rules , but I would like to see implemented the "forced password change" rule.



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