Heads up - Anaconda 22.17 will enforce 'good' passwords

[David Cantrell]

I think the main point is the one nirik made; I don't think the devs
agree with your assessment of how significant this is. It's a minor
inconvenience; you just have to come up with a password that passes
the check, or use a kickstart. So I don't think they agree that it
needs a full-blown security audit and FESCo review or whatever,
because they don't think it's really that huge of a change in
behaviour.

Having to come up with a password that passes the check is not 'a minor
inconvenience'. Given how capricious libpwquality is about scoring
(there have been some examples in this thread, there are more in
gnome-initial-setup bugs), it is next to impossible.
This discussion has been pretty heated, but I agree with there being
some aspect of 'collective punishment' here: just because _some_ systems
get installed with sshd enabled, all users who install the Workstation
have to spend a couple of frustrating minutes trying to find a password
that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way
to the workstation installer not enforce this. I know the anaconda folks
are not eager to add variations like this, but that is exactly what we
need: If you want to enforce product-specific policy in the installer,
it needs to be a product-specific installer.

You're assuming before asking. With the structure of the installer now, we
can look at changes like taking the password aspect and making it
product-specific controllable by a number of different methods. Our
historic aim to end variant specifics in the installer was because the old
code (and variants) lacked a way to assign owners to those product
specifics, which meant that requests of the installer to be product specific
meant we were asked to be the owners of those specifics.

Let me ask now, then: can we make the change to reject 'weak' passwords
specific to only those products that enable sshd by default, please ?

[adding anaconda-devel-list to CC]

From a technical standpoint, I see this being possible. Conditionalize it

on sshd being enabled or not. That's not really variant-specific and just a
system condition we could work around.

I'm putting this on anaconda-devel-list for further discussion. bcl,
others? What are your thoughts on this request?

[Brian C. Lane]

Post by David Cantrell

I think the main point is the one nirik made; I don't think the devs
agree with your assessment of how significant this is. It's a minor
inconvenience; you just have to come up with a password that passes
the check, or use a kickstart. So I don't think they agree that it
needs a full-blown security audit and FESCo review or whatever,
because they don't think it's really that huge of a change in
behaviour.

Having to come up with a password that passes the check is not 'a minor
inconvenience'. Given how capricious libpwquality is about scoring
(there have been some examples in this thread, there are more in
gnome-initial-setup bugs), it is next to impossible.

Next to impossible? Really? I've find it easy to come up with passwords
that work. We even report libpwquality's reason for any failures.

Post by David Cantrell

This discussion has been pretty heated, but I agree with there being
some aspect of 'collective punishment' here: just because _some_ systems
get installed with sshd enabled, all users who install the Workstation
have to spend a couple of frustrating minutes trying to find a password
that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way
to the workstation installer not enforce this. I know the anaconda folks
are not eager to add variations like this, but that is exactly what we
need: If you want to enforce product-specific policy in the installer,
it needs to be a product-specific installer.

You're assuming before asking. With the structure of the installer now, we
can look at changes like taking the password aspect and making it
product-specific controllable by a number of different methods. Our
historic aim to end variant specifics in the installer was because the old
code (and variants) lacked a way to assign owners to those product
specifics, which meant that requests of the installer to be product specific
meant we were asked to be the owners of those specifics.

Let me ask now, then: can we make the change to reject 'weak' passwords
specific to only those products that enable sshd by default, please ?

[adding anaconda-devel-list to CC]

From a technical standpoint, I see this being possible. Conditionalize it

on sshd being enabled or not. That's not really variant-specific and just a
system condition we could work around.
I'm putting this on anaconda-devel-list for further discussion. bcl,
others? What are your thoughts on this request?

I don't think we should make it act differently. While the change
request for sshd setup was the initial reason I wrote the changes, I
think that ALL passwords on the system need to be strong these days.

I don't find any of the arguments against the change to be compelling.
The most valid one is repeated installs of throw-away VMs, and I
addressed that in my original post. Just make up a password that passes
and write it down.

If we do make this conditional, either based on sshd being active, or
per-product then where do we stop? Most decisions the installer makes
about the system could be called 'enforcing', so do we now have to have
a vote on every change?

Passwords are the gateway to people's private data. We should be
encouraging them to choose stronger passwords and we should remember
that we're not the only people running Fedora.

[Chris Murphy]

Post by Brian C. Lane
Next to impossible? Really? I've find it easy to come up with passwords
that work.

You think this is easy. Other's don't. It's a condescending,
pointless, and unwinnable argument, and it needs to stop.

I tried anaconda 22.17. I failed to produce an acceptable 8 character
password, and tolerated a 10 character one to appease the installer,
which was promptly forgotten 1/2 an hour later. While humorous, it
also pissed me off. That's not a good UX by definition but I know you
tend to discard negative UX whenever you disagree with the actions of
the user.

Post by Brian C. Lane
I don't think we should make it act differently. While the change
request for sshd setup was the initial reason I wrote the changes, I
think that ALL passwords on the system need to be strong these days.

You keep trying to frame this as weak vs strong passwords, and that's
simply wrong. It's a very weak vs weak password difference, yet it
comes with a disproportionate burden on the user. Every single device
I own, and even ATMs I don't own, have better security and a truly
easy UX than this policy proposes.

Post by Brian C. Lane
I don't find any of the arguments against the change to be compelling.

I also notice how many times you defend this policy change with "I".
You find it easy, you think it's needed, you find others' arguments
uncompelling. It's just more of the same casting aside of user
opinions that you merely disagree with. And disagreement with the
opinions of others isn't a defense that withstands scrutiny.

Do you find it conspicuous that in a ~70 email thread that no one
except you has posted in favor of the change? The strongest statement
in favor of it that I've read, other than yours, is from sgallagh, in
the Server WG meeting minutes. [1]

16:34:28 <sgallagh> A more reasonable approach would be to just
enforce a better root password (not more complex, just longer)

Adamw's hyperbole notwithstanding, his sentiment in that same meeting
is compatible with mine: quit job, and buy a yak farm instead of
typing long passwords a dozen fking times a day.

I surmise the Server WG would reject the current behavior in 22.17
also due to the (capricious) complexity required, and if so there
wouldn't be a misalignment requiring separate behavior between Server
and Workstation.

Post by Brian C. Lane
We should be
encouraging them to choose stronger passwords and we should remember
that we're not the only people running Fedora.

Encourage: - give support and advice to (someone) so that they will do
or continue to do something
Coerce: - persuade (an unwilling person) to do something by using
force or threats

22.17 forces me to use a weak instead of very weak password, or I'm
disallowed from installing. That behavior meets the definition of
coercion, not encouragement.


[1]
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-1.2015-01-13-16.00.log.html

[Máirín Duffy]

Post by Brian C. Lane
Next to impossible? Really? I've find it easy to come up with passwords
that work. We even report libpwquality's reason for any failures.

'my name is' (good) (10 chars)
'bacon4eva!' (strong) (10 chars)
'hamncheese.' (strong) (10 chars)
'GoPatriots!' (strong) (11 chars)
'hey, you!' (good) (8 chars)
'8crayons.' (good) (9 chars)
'latte2015' (good) (9 chars)


I tried making up some passwords in Anaconda in F21, which uses the same
library. I had a difficult time making a password rated less than good
when I made passwords that were 10 characters with only lowercase
letters and no spaces or special characters. Add spaces, a punctuation
mark, or caps and it is instantly easier. I had a much harder time
making a new acceptable password for my Twitter account.

Is the concern that 10 chars is too long?

~m

[Leslie S Satenstein]

 Regards
 Leslie
Mr. Leslie SatensteinMontréal Québec, Canada


From: Máirín Duffy <***@redhat.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-***@redhat.com>
Cc: For testing and quality assurance of Fedora releases <***@lists.fedoraproject.org>
Sent: Thursday, February 5, 2015 4:03 PM
Subject: Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

Post by Brian C. Lane
Next to impossible? Really? I've find it easy to come up with passwords
that work. We even report libpwquality's reason for any failures.

'my name is' (good) (10 chars)
'bacon4eva!' (strong) (10 chars)
'hamncheese.' (strong) (10 chars)
'GoPatriots!' (strong) (11 chars)
'hey, you!' (good) (8 chars)
'8crayons.' (good) (9 chars)
'latte2015' (good) (9 chars)


I tried making up some passwords in Anaconda in F21, which uses the same
library. I had a difficult time making a password rated less than good
when I made passwords that were 10 characters with only lowercase
letters and no spaces or special characters. Add spaces, a punctuation
mark, or caps and it is instantly easier. I had a much harder time
making a new acceptable password for my Twitter account.

Is the concern that 10 chars is too long?



~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-***@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


All passwords of 8 characters are good, but some are better than other.
In the past, I while installing, I used the simplist of passwords. On first logon, I then created a more sophisticated one, using  € and ¥ and some other characters.
For testing I propose to use ###abc123   for nine characters. Don't know if letter repeats of more than 2 characters will be permitted. It would be nice to have the acceptance rule.

[Kamil Paral]

Post by Máirín Duffy

Post by Brian C. Lane
Next to impossible? Really? I've find it easy to come up with passwords
that work. We even report libpwquality's reason for any failures.

'my name is' (good) (10 chars)

weak

Post by Máirín Duffy
'bacon4eva!' (strong) (10 chars)

fair

Post by Máirín Duffy
'hamncheese.' (strong) (10 chars)

fair

Post by Máirín Duffy
'GoPatriots!' (strong) (11 chars)

good

Post by Máirín Duffy
'hey, you!' (good) (8 chars)

weak

Post by Máirín Duffy
'8crayons.' (good) (9 chars)

fair

Post by Máirín Duffy
'latte2015' (good) (9 chars)

weak


So, 3 of your 7 proposed passwords are not allowed in Anaconda.

All of these are also weak (8 characters randomly typed on the keyboard, containing an uppercase letter, a number and a special character):

mT5&sofj
lk6m*Afh
4muDb^pd
***@tYu9vb
... and I assume *everything else* based on this formula, according to my testing.


I wonder why is my experience so vastly different from yours?


[1] https://fedoraproject.org/wiki/Test_Day:2015-02-12_Anaconda_DNF

[Máirín Duffy]

Post by Kamil Paral
I wonder why is my experience so vastly different from yours?

I have no idea. I used F21 final. Has the library changed that much
since then?

~m

[Chris Murphy]

Post by Máirín Duffy

Post by Brian C. Lane
Next to impossible? Really? I've find it easy to come up with passwords
that work. We even report libpwquality's reason for any failures.

'my name is' (good) (10 chars)
'bacon4eva!' (strong) (10 chars)
'hamncheese.' (strong) (10 chars)
'GoPatriots!' (strong) (11 chars)
'hey, you!' (good) (8 chars)
'8crayons.' (good) (9 chars)
'latte2015' (good) (9 chars)
I tried making up some passwords in Anaconda in F21, which uses the same
library. I had a difficult time making a password rated less than good

when

Post by Máirín Duffy
I made passwords that were 10 characters with only lowercase letters and

no

Post by Máirín Duffy
spaces or special characters. Add spaces, a punctuation mark, or caps and

it

Post by Máirín Duffy
is instantly easier. I had a much harder time making a new acceptable
password for my Twitter account.

I don't see how that's possible. Twitter has a clear guideline enabling the
building of a minimum acceptable password such that I can do it in a single
attempt. Anaconda doesn't define anything at all. It just complaints "too
weak" but doesn't state what I need to do to fix it. Make it not weak? Duh,
but that's not helpful.

I enter in a 6 character password, I'm told it's too weak and that it
doesn't contain at least 7 characters. I enter in 7 characters, and I'm
told merely that it's too weak. OK the minimum is apparently 7 characters
yet I can't find a single 7 character combination to appease the weak
rating. Is it 8? I've already spent more time creating passwords in this
single build of Anaconda, than the total cumulative time I've spent
creating, modifying, resetting, and using my Twitter password.

In any case, it's reasonable for online services to require minimum
password quality. It's not reasonable for Fedora to do this for my devices.
There is no service in this context.

Post by Máirín Duffy
Is the concern that 10 chars is too long?

The concern is that it's not Fedora's hardware. It's my device, I get to
decide what the password quality and the password are. Even proprietary
products respect this long standing practice. This has the feel of Fedora
usurping a kind of control over my hardware that doesn't even exist on
proprietary OS's (let alone other Linux distributions).

Yes, 10 characters is too long, I think this requirement will make users
mad. I'm disinclined to do any further installer testing because of this
change, and the manner in which it was done.

I'm also concerned about CoC warnings and sanction on ***@. This is the
list were users volunteer to be abused by software, as such I think they're
more tolerant. And yet this misfeature hasn't been well received at all
here, overwhelmingly. I'd expect the reception in the rest of the community
would be quite a bit less docile.


--
Chris Murphy

[Adam Williamson]

the list were users volunteer to be abused by software, as such I
think they're
more tolerant. And yet this misfeature hasn't been well received at
all here, overwhelmingly. I'd expect the reception in the rest of
the community
would be quite a bit less docile.

On this topic: no-one was warned or sanctioned for complaining about
the change. They were warned and sanctioned for complaining about it
in a manner which was *clearly* against the code of conduct. As a mod
of test@ I do not want to see it turn into the kind of cesspool devel@
can become; that kind of atmosphere is a significant contributing
factor to people not wanting to read or contribute to that list and we
really don't want that to happen to ***@.

[Matthew Miller]

Post by Adam Williamson
in a manner which was *clearly* against the code of conduct. As a mod
can become; that kind of atmosphere is a significant contributing
factor to people not wanting to read or contribute to that list and we

For the record, I want it to _stop_ happening on devel. Both the
nastinesss and threads which go back and forth with no new information
added — the latter aren't as overtly damaging as the former but still
contribute to list fatigue and don't actually help influence the people
who need influencing.

[Adam Williamson]

the list were users volunteer to be abused by software, as such I
think they're
more tolerant. And yet this misfeature hasn't been well received at
all here, overwhelmingly. I'd expect the reception in the rest of
the community
would be quite a bit less docile.

On this topic: no-one was warned or sanctioned for complaining about
the change. They were warned and sanctioned for complaining about it
in a manner which was *clearly* against the code of conduct. As a mod
of test@ I do not want to see it turn into the kind of cesspool devel@
can become; that kind of atmosphere is a significant contributing
factor to people not wanting to read or contribute to that list and we
really don't want that to happen to ***@.

[Leslie S Satenstein]

From: Adam Williamson <***@redhat.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-***@redhat.com>
Sent: Monday, February 9, 2015 10:11 PM
Subject: Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

the list were users volunteer to be abused by software, as such I
think they're
more tolerant. And yet this misfeature hasn't been well received at
all here, overwhelmingly. I'd expect the reception in the rest of
the community
would be quite a bit less docile.

On this topic: no-one was warned or sanctioned for complaining about
the change. They were warned and sanctioned for complaining about it
in a manner which was *clearly* against the code of conduct. As a mod
of test@ I do not want to see it turn into the kind of cesspool devel@
can become; that kind of atmosphere is a significant contributing
factor to people not wanting to read or contribute to that list and we
really don't want that to happen to ***@.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

_______________________________________________
 
I concur with Adam about this discussion issue.
May I post this message, as a senior citizen who, for 50 years, worked in software architecture and in security (in banking) for many years?

On the fedoraforum.org site, I posted that I use "12345678" during the anaconda installation. After first installation boot at first logon, I replace that simple password with a stronger one. The practice I follow was based on two habits.


I revise system keyboard layout definitions to allow € and ¥ so that any of the characters from "#@£¢€¥" can be used within my post anaconda password.  The second practice stems from my experience. 
Within big shops, the techie that installs Linux is not normally one of the system administrator(s).


Therefore, in big shops, there always a password change on a handover to one or more system administrators.  First boot, first logon is a good handover point in time. 

With this proposed new rule,  I will be using a simple password "###123abc###"  as a replacement for 12345678?   Is that the entire issue about usable passwords during the anaconda operation? 

If you really want secure passwords,  enforce a password change on the user's first logon and prevent the user from overwriting linux password vetting rules.
 Regards
 Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada