PDA

View Full Version : Newest Anaconda to enforce passwords



smr54
29th January 2015, 02:03 PM
This Friday's build of Anaconda will no longer allow you to use weak
passwords and click done twice. In order to promote more secureish
default systems I have increased the password length required to 8
characters and removed allowing weak (as defined by libpwquality)
passwords.

Just a heads up for those who use rawhide and have missed the announcement on the testing list.

antikythera
29th January 2015, 02:47 PM
Good move. I believe all OS should set a higher emphasis on the use of stronger passwords. Especially on accounts with root or admin rights.

8 characters is still fairly weak unless you randomise a password from a mix of lowercase,uppercase,numeric and special characters. Then at least you'd have a modicum of password strength. I use minimum 16 when setting passwords.

e.g. pineappl is 8 characters and about as much use as a chocolate fireguard.

2Hu&1a%n is better.

No actual passwords were harmed (that I'd use anyhow) in the making of this post...

JoshuaA
31st January 2015, 01:07 AM
I think it totally sucks.

This should be left up to the user -- maybe suggested but not enforced by the OS.

The hours wasted by everyone who will use Fedora vs the select few who need such a policy does not justify it!

lsatenstein
31st January 2015, 05:33 AM
Just a heads up for those who use rawhide and have missed the announcement on the testing list.

What a shxxxy idea. Really. let me explain why I believe so and provide a better alternative solution.

I use a Canadian French keyboard and corresponding layout. My after installation root passwords always contain one or more characters from

é É È ô « » # € ¥ and even ¼ ½ ¾ and ¢

On a second computer, I have the latam keyboard and use that layout (Latin American Spanish). I can include the inverted ! ? in addition to most of the previously listed characters.

So, my practice has been to use 12345678 for a root password,only during installation, and on the first root login, to immediately change the root password to a more complex one.

I do that « second password » change after I am certain that the virtual terminal layout is « ca » and the keyboard layout has been properly setup as the default.

Many times from the command line, after a reboot, I had to run « localectl set-x11-keymap ca pc105 » so I could enable that Canadian French keyboard layout. However, if I used one of the above listed characters in a password during anaconda setup, and if the keyboard failed to be setup correctly (verify via ctl-alt-f2...ctl-alt-fn) some of my password characters cannot be entered at all, as a few of them are not available on the default « us pc105 » layout.

What are my choices when the character can't be entered?

a) reinstall using a simpler password. A few times I have followed this option.
b) Use the emergency flash-drive image to boot the new Fedora release in order to recreate the passwords.
c) use a simple password and change it to something more complex on first post installation login..
d) While anaconda is running, enter terminal mode and run the passwd command for root.

My ideal solution would be to enforce Linux's password expiry:
Use Linux's ability to force a « password change » on a first login. In other words, allow the simple password and force the user (root, and/or admin and/or standard user) to install a new password on a first login. This password expiry method is a standard option with all Linux distributions.

A second reason why it is a poor decision.

Via command line, I can force any password I want for any user. I just ignore the warning message.

I do not see any increase in security by choosing the method of password creation during an anaconda installation of Fedora. It will mean I have to learn to use 1234###abc as an anaconda root and admin passwords and I will change them at first login.

Put your energies elsewhere, just insure any 8 characters from, pc105 layout.

nonamedotc
3rd February 2015, 03:10 AM
To me personally, it's not a big deal. I have a "complex" password for all my test VMs ... the discussion on test@ has been very interesting nevertheless - which I have been following from the start.

Dutchy
3rd February 2015, 01:15 PM
So for my playground VMs I now need to first come up with some bogus hard to crack password before I can remove it again after installation.
This is pure bull crap and not necessary at all since this is already enforced through non-root passwd and Gnome's user add/password management.

nonamedotc
3rd February 2015, 01:41 PM
So for my playground VMs I now need to first come up with some bogus hard to crack password before I can remove it again after installation.
This is pure bull crap and not necessarily at all since this is already enforce through non-root passwd and Gnome's user add/password management.

This is exactly what lot of people on test@ are also saying - and I do agree (even if it doesn't affect me). The reasons given for this change strike me as odd though ..

smr54
3rd February 2015, 03:34 PM
The one statement that does make sense is that it's because RedHat (and Fedora) allow root login by default through ssh. I'm not sure how most other systems deal with it, FreeBSD denies it by default, with OpenBSD, if you create a user during install, you're given the option of denying root ssh login. Ubuntu, OSX and friends don't create a root user.

The general reaction has been negative. I mentioned it on the CentOS list too, because I'm a troll (my serious motive was that those who don't pay attention to Fedora things get shocked when they hit REHL and therefore CentOS), and the discussion there has been interesting too.

antikythera
3rd February 2015, 04:04 PM
 I Change all my passwords to "incorrect". So whenever I forget, it says, "your password is incorrect". - steve carell ...

rbmorse
3rd February 2015, 05:36 PM
I'm opposed to this change as well. I'm the only person with access to this machine. What useful purpose is served by making me deal with a complex password?

pugwash
7th February 2015, 05:14 PM
I think this is an extremely bad idea. We do not need the nanny state in linux. This type of enforcement generally comes from people with a mistaken vision of their rights and duty and attempt to make everyone conform to their vision. We do not tolerate that attitude in our governments. Freedom is basically defined as the right to not obey.

smr54
7th February 2015, 05:52 PM
I don't know what happens if ordinary users write the FESCo people. I know that on the list it was asked that they revert the change, and if they felt that strongly about it, request it through FESCo, but have no idea if one any individual (or individuals) can do the opposite, that is request through FESCo that it be reverted. When I asked on the list where one could complain, the testing list itself was given as a place to complain but despite almost universal disapproval, I haven't heard of it being reverted. The CentOS list who is now also aware of it, is almost universally against it too, and that list has lots of people who use it for a living.

Maybe someone needs to submit it to slashdot, and, if it's ridiculed by most, as I would think it would be, that will convince them to change it, but frankly, I have no idea. As far as I see, (WARNING--NOT DEEPLY INVESTIGATED, QUITE POSSIBLY FUD), one person decided to do it, did it, announced it, and that was that

rbmorse
7th February 2015, 06:25 PM
I think this is an extremely bad idea. We do not need the nanny state in linux. This type of enforcement generally comes from people with a mistaken vision of their rights and duty and attempt to make everyone conform to their vision. We do not tolerate that attitude in our governments. Freedom is basically defined as the right to not obey.

Quite agree. Plus it will have a negative effect of motivating users who are content to put up with simple passwords to start logging in as root to avoid having to enter a complex password more than once a session. This is a bad idea all around.

lsatenstein
7th February 2015, 06:50 PM
So for my playground VMs I now need to first come up with some bogus hard to crack password before I can remove it again after installation.
This is pure bull crap and not necessary at all since this is already enforced through non-root passwd and Gnome's user add/password management.

While anaconda is running, you can enter command line and set a password, or even add a third user. To return back to the GUI, only by ctl-alt-f6.

(I tested this. It applies only to the linux that runs anaconda, and not to the target linux.

upnort
7th February 2015, 09:59 PM
I am relatively new to Fedora since this past summer. Yet I have been using Linux based systems for more than a dozen years. I do not like this idea of password enforcement.

While passwords limit non technical nosy people and prevent cats from rebooting a locked screen, passwords do not stop hard-core hackers or technically savvy users. Hacking into a user's account is as easy as using a live CD/USB. Or removing the hard drive and mounting in a different system. Without disk encryption passwords provide no serious protection outside of nominal defense at the keyboard.

I understand the need for password support in an enterprise environment. In the home environment the usefulness of passwords is debatable. IT folks in an enterprise environment often install systems from cloned images, not from an installer and have their own in-house password policies that activate the first time a user logs in. Most users who install a fresh system using an installer are likely to be non enterprise users, likely home users.

Adding password enforcement in the installer is like teaching cows to sing. A waste of time and the cows get irritated. :)

Please do not add password enforcement.

smr54
7th February 2015, 10:14 PM
Keep in mind that this forum is just for users helping other users with no official connection to Fedora. Of course, one problem is that as far as I can tell, the person who made the decision did it in such a way that there's really no official channel to complain, just the Fedora-testing list, where there's been a great deal of protest. So there is hope that it may be changed.

kkshethin
8th February 2015, 08:08 AM
a very bad decision.
I understand that this is not a proper place for writing.
I hope against hope that some one from fedora atleast visit this forum and listen to voice of reason.
Now a days, there are more such decisions happening. What we should call those? Political correctness

antikythera
8th February 2015, 11:22 AM
This post is nothing personal against anyone in this thread. People do have a say but either voice it in the wrong circles or do nothing about it. The number of voters for the publicised Engineering Committee election recently indicated a general level of apathy to me about the steering of the Project. How many thousands of users are there? Only 283 of us voted.

If the password change in anaconda is so important then please voice your concerns on the appropriate mailing list. Then if enough people object they might take note and either reverse the decision or make some form of opt-out available.

lsatenstein
9th February 2015, 03:45 AM
Hi arehtykitna

I wrote to the design mailing list but that list is only for gui designs.
I wrote to the anaconda mailing list, but that list is only for anaconda issues
I stopped writing, because in the end it is no big deal.
Because my default logon password will be ##12ab##12## and if ##1234#### is accepted under the new rules, I will use that practice.

That decision is not well thought out for a few reasons. In a large shop, the root password is shared between sysadmins. The person doing the installation is the hardware / software guy and usually not the system admin or the security guy. The latter two want to set and record a password and put it into an envelope.

The practice I follow is to use 12345678 during anaconda installation and on first login to the installed Fedora Linux, to change the password to something respecting corporate norms. (I am the corp in my house).

Are you aware that after launching anaconda and after the passwords were accepted, that one can still get into Linux that powers anaconda and issue user creations and password changes. I will try it later this evening to determine if those are migrated into the Fedora 21 Linux that is installed.

During anaconda execution, a password of 12345678 for root and 12345678 for the admin are fine. I proposed an alternative security solution. which was to accept simple passwords at this point in time and to set up Fedora Linux users to require a forced password change on a first login. That means, after a reboot, when root logs in, a forced change is imposed. and likewise for the administrator.

Is there a justification which we are not considering? If Linux today requires a password to be vetted for conformity to some password format rules, are the anaconda developers likely to use the Fedora Linux with those incorporated rules to drive anaconda? Developers may be passing on the result of the Linux password vetting routine as they would not have to modify the Linux on which anaconda executes.

In closing, in place of 12345678 I will be using ##12ab##12ab (12 chars ) during the anaconda installation

smr54
9th February 2015, 12:03 PM
The justification is that RH/Fedora allows root login by ssh.

The test list was the supposed place to complain, but as far as I can tell, the myriad of complaints there were also ignored. Despite some respected names asking for it to be removed, as far as I can tell, the one person who decided it is ignoring such requests.

I suspect one could complain to FESCo, which is what the person who originally decided this should have done to request this change, but I think that it's going to be one more of those bad ideas that get in there, because it's like a hiccup--highly annoying, but not that serious.

antikythera
9th February 2015, 01:56 PM
will this suffice? https://fedorahosted.org/fesco/ticket/1412 ;)

smr54
9th February 2015, 05:34 PM
Well, it's certainly a start, thank you.

sea
9th February 2015, 07:15 PM
What about the freedom of choosing (to set) no password at all?

BBQdave
9th February 2015, 07:29 PM
What about the freedom of choosing (to set) no password at all?

I would offer that "1234" is no password :)

I am curious, and admittedly this drifts a little from the original post, but I am hearing of devices activated by fingerprint. Smart devices that use your fingerprint as the pass.

I don't know much about this, and wonder if that really will replace character passwords?

antikythera
9th February 2015, 07:37 PM
In theory it could already on capable/compatible notebooks. fprintd, one of the packages I removed from my installation supports fingerprint readers.

chrismurphy
9th February 2015, 07:46 PM
What about the freedom of choosing (to set) no password at all?

Like on mobile devices (Android and iOS)? I think so, and if not, why not? What's not being done correctly to lock down a laptop, that is being done that makes this acceptable on a phone or tablet?:confused:

sea
9th February 2015, 08:09 PM
Like on mobile devices (Android and iOS)? I think so, and if not, why not? What's not being done correctly to lock down a laptop, that is being done that makes this acceptable on a phone or tablet?:confused:

We are talking about Fedora, which i consider to be a computer/laptop oriented distro?

Personaly, i appreciated the 'current' way very much.
It let me choose a weak password, but warned me that its weak, but it did let me continue if i wanted to.

The freedom was maintained.
When its forcing me to use a password of XY strength according to rule XA, regardless of my choice, i feel my freedom cut.

chrismurphy
9th February 2015, 08:31 PM
We are talking about Fedora, which i consider to be a computer/laptop oriented distro?

I don't understand the distinction. Mobile devices are in every way used in more risky environments, users routinely have them on unencrypted wifi, and yet device passwords aren't required at all. So why require a password, let alone a faux-strong password on Fedora on a laptop? What's the argument in favor? I've asked this numerous times in the test@ thread and still have no answer other than platitudes.



When its forcing me to use a password of XY strength according to rule XA, regardless of my choice, i feel my freedom cut.

OK but your freedom gets cut in numerous cases that you accept, Google, Twitter, even this site, have stronger password requirements than Anaconda.

Should people be free to present their hardware on a network with a vulnerability that enables it to be added to a malicious botnet?

The freedom argument is nebulous. So why is it OK for a service like fedoraforum.org, but it's not OK for the Fedora installer?

sea
9th February 2015, 08:46 PM
Simple:
Because on MY device, i want MY rules to apply.
On the forum, its service of others i use, thus i have to accept their terms.

Detail:
Sure i accept their password rules of google, twitter, facebook etc, but those are online services, and strong passwords requirements there are necesary due to beeing exposed to the internet.
Whereas for a device, that i do not connect to the internet at all and which doesnt leave the house, i dont want to be forced to meet security requirements that the environment doesnt need.

By your argueing, i'd conclude to apply this stronger password enforcing method for ARM builds, which are ment to be used for mobile devices, which require a higher security level, due to beeing exposed to the public - in some way.
And just because a regular i386/x86 iso can be installed on a laptop/netbook, doesnt mean that everyone is carrying it around.
In fact, companies aside, of those people i know having a (therefor personal) laptop, only 1 is carrying it outside the very own house the laptop is located in.

And that is me, using encrypted partitions and strong passwords.
But for my other device wich i never carry outside, and also using encryption, i dont want to set any other passwords but the encryption one.

As already stated, and beeing aware of the 'felt' need of higher security, i apreciate the way it is until F20.
It indicates how strong the password is (red-green-bar, allthough for root and users there are diffrent criteria), and when a password is set below the minimal suggested requirement, it warns me that i had used a weak password and should change it.
But if i do not want to change it, it lets me use it either way.

If one is dumb enough to install Fedora on a mobile device and using no password, or 1234 as the root/device password, its one own's dumbness.
But heck, if i dont want a password on a machine that doesnt leave my house, i dont want to be forced to use 12 character long one..

chrismurphy
9th February 2015, 09:24 PM
Sure i accept their password rules of google, twitter, facebook etc, but those are online services, and strong passwords requirements there are necesary due to beeing exposed to the internet.
Whereas for a device, that i do not connect to the internet at all and which doesnt leave the house, i dont want to be forced to meet security requirements that the environment doesnt need.

What you're saying is, the context and use case matter.


By your argueing, i'd conclude to apply this stronger password enforcing method for ARM builds, which are ment to be used for mobile devices, which require a higher security level, due to beeing exposed to the public - in some way.

Well in fact the opposite. Mobile devices are, by nature, encountering more public unencrypted networks than even a typical laptop. Yet all laptop OS's have some kind of password minimum, even if it's only 4 characters, even if you can enable automatic logins by default. Whereas mobile devices don't have any password requirements at all for the device itself. You can opt for just a slide lock, not even a 4 digit PIN is necessary.

So far that's reasonable. I don't lock or put a password on my wallet, why do I need one on my phone? My phone in particular has less risk of bad things happening if it were lost than my wallet, which would take hours to deal with all the lost credit cards and ID's.



As already stated, and beeing aware of the 'felt' need of higher security, i apreciate the way it is until F20.
It indicates how strong the password is (red-green-bar, allthough for root and users there are diffrent criteria), and when a password is set below the minimal suggested requirement, it warns me that i had used a weak password and should change it.
But if i do not want to change it, it lets me use it either way.

I think the password quality indicator in the installer is too generous. But password quality also depends on rate and reattempt limits. Obviously 4 digit PINs are considered (barely) adequate by banks for ATM use to get cash. So if we have rate limiting, and a key derivation function that's designed to intentionally make password confirm/deny slow, by default, I think we can tolerate much lower quality passwords with minimum risk.

Obviously Android and iOS get away with no passwords because they aren't running any services themselves by default. So the question needs to be, what services cause vulnerability and does it really make sense to enable them by default? Some server folks might get mad if sshd isn't enabled by default. But that's the typical enterprise setup for Windows and OS X servers (don't laugh, keep it on topic!), the expectation is you connect a USB keyboard to the server, or user serial/ethernet console access to enable the services you want. They aren't enabled by default.



If one is dumb enough to install Fedora on a mobile device and using no password, or 1234 as the root/device password, its one own's dumbness.

On phones, no password at all is extremely common.



But heck, if i dont want a password on a machine that doesnt leave my house, i dont want to be forced to use 12 character long one..

My argument from the very beginning has been that context matters. And thus far the proponent(s) haven't responded to this other than passive disagreement, suggestion passive support for a compulsory minimum password strength as a public good. And this, even though no one else does that. And I think it's unacceptable this isn't being answered adequately.

Keep in mind the original context of the complaints about this policy aren't actually normal users (I'm making that argument also), but rather test users who don't want to have to come up with longer stronger passwords when doing a dozen installs per day.

Thing is, since this password policy and my initial testing of the installer, I haven't tested it since. And at this point I'm disinclined to.

chrismurphy
10th February 2015, 03:38 AM
This post is nothing personal against anyone in this thread. People do have a say but either voice it in the wrong circles or do nothing about it. The number of voters for the publicised Engineering Committee election recently indicated a general level of apathy to me about the steering of the Project. How many thousands of users are there? Only 283 of us voted.

I agree. Even if a majority of just package maintainers were to vote, this number would be high.


If the password change in anaconda is so important then please voice your concerns on the appropriate mailing list.

That would be devel@.


Then if enough people object they might take note and either reverse the decision or make some form of opt-out available.

Sure. The problem I have with this is, it's history repeating itself: do not solicit input, do not engage in objective analysis or debate, instead try to shut down the discussion, wait for sh|t show on devel@, and then with equal silence revert the change. I'm referring to the 2013 installer change where the user password was fully displayed instead of masked behind bullets. The bug. (https://bugzilla.redhat.com/show_bug.cgi?id=958608) And the devel@ discussion. (https://lists.fedoraproject.org/pipermail/devel/2013-May/182196.html)

I don't think this is a good process to follow.

kkshethin
10th February 2015, 02:30 PM
My argument from the very beginning has been that context matters. And thus far the proponent(s) haven't responded to this other than passive disagreement, suggestion passive support for a compulsory minimum password strength as a public good. And this, even though no one else does that. And I think it's unacceptable this isn't being answered adequately.

Keep in mind the original context of the complaints about this policy aren't actually normal users (I'm making that argument also), but rather test users who don't want to have to come up with longer stronger passwords when doing a dozen installs per day.

What is public good. It is debatable from the very start. Is it a policy decided by someone. Why this password policy, if it was so good, not applied before for public good.

And who is to decide that this is not a argument from normal users and only by so called developers. Are developers not themselves normal users in some reference and contexts

antikythera
10th February 2015, 08:25 PM
Sure. The problem I have with this is, it's history repeating itself: do not solicit input, do not engage in objective analysis or debate, instead try to shut down the discussion, wait for sh|t show on devel@, and then with equal silence revert the change. I'm referring to the 2013 installer change where the user password was fully displayed instead of masked behind bullets. The bug. And the devel@ discussion.

I don't think this is a good process to follow.

Chris, maybe history is repeating. I was not aware of the previous issues (see Join date) or any pre-existing negativity already felt towards developers as a result.

All I would say is that having had the chance to read through the information Adam W posted to the FESCo ticket I was not impressed by the impetuous posts of some of the participants and can see why he felt he needed to apologise on their behalf.


Comment (by adamwill):

There's been discussion of this change on anaconda-devel-list and test as
well, providing those threads for completeness:

https://lists.fedoraproject.org/pipermail/test/2015-January/124827.html
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.html

I apologize on behalf of Da Community for the tone of some of the comments
on the test@ list, but there is some constructive discussion in there too.

Your suggestion of a product specific setting isn't a bad idea. I wonder about the spins though. Depending on which product they are based on it would affect them still. e.g. MATE-Compiz comes with GNOME Keyring SSH-Agent in startup applications plus openssh, openssh-clients, openssh-server installed. So I removed them all after install along with the startup entry.

So maybe something in the KS file could specify appropriate anaconda password behaviour?
e.g. nopwdrefusal=1

Again it would depend on the developers being amenable to the idea and able to implement it.

lsatenstein
10th February 2015, 08:53 PM
Why can't we go back to password management as it was in the old prior to anaconda days? Allow us to create the user logons and forget passwords on first boot.

I previously posted that I use "12345678" during the anaconda installation. Following 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 on the hardware 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. There is also a password change when a system administrator leaves the department.

With this proposed new rule, I will be using a simple password "###123abc###" as a replacement for 12345678? Linux password validation accepts it happily. 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.

BBQdave
10th February 2015, 09:55 PM
Mobile devices are, by nature, encountering more public unencrypted networks than even a typical laptop. Yet all laptop OS's have some kind of password minimum, even if it's only 4 characters, even if you can enable automatic logins by default. Whereas mobile devices don't have any password requirements at all for the device itself. You can opt for just a slide lock, not even a 4 digit PIN is necessary.

For me, it's an Android device on my trusted home network or Sprint's data service. No need to be on an un-trusted public network, such as at the airport or a cafe.

I think you are mixing what is password protected and what is open (by nature). Connecting to make a call does not require a password. Connecting to the internet requires a password (wifi). Android with Google account, you have a password - chrome is tied to this. You can password protect your device or - the same as choosing auto login with a computer. Most service accounts (I can not think of one with out a password) uses passwords.

As always, how strong the password is, and whether you choose to auto login (or not have your phone locked) is up to the user.

antikythera
11th February 2015, 10:19 PM
mitr has been tidying up my FESCo ticket's formatting and added keyword: meeting

I take that as a good sign they will discuss this issue as requested.

chrismurphy
12th February 2015, 06:41 AM
Chris, maybe history is repeating. I was not aware of the previous issues (see Join date) or any pre-existing negativity already felt towards developers as a result.

I disagree there's any pre-existing negativity. I can only speak for myself, and I think the change is inappropriate, and I really don't like it.


All I would say is that having had the chance to read through the information Adam W posted to the FESCo ticket I was not impressed by the impetuous posts of some of the participants and can see why he felt he needed to apologise on their behalf.

The very fact people are expressing with heightened emotion should impress upon anyone the change is inducing stress and frustration, therefore more scrutiny for the change is warranted, not less. The emotion is a symptom of a problem, it's not the problem itself.



Your suggestion of a product specific setting isn't a bad idea.

That idea was 50% serious, and 50% turd polishing. Since I don't agree with the change, I think ways to keep the change while improving the behavior is wasted effort. Aside from the distinctly capricious and resulting negative UX, I think it's very distracting from the real issue of how to mitigate the risks this change poorly addresses: better defaults, and better hardening mechanisms.


So maybe something in the KS file could specify appropriate anaconda password behaviour? e.g. nopwdrefusal=1

A mechanism to make it easier for the proper authority to enforce stronger passwords for user creation (at installation time or post-install) sounds good. My objection is with the connotation of official Fedora products questioning the user's use case, good judgement, authority, and matters of convenience.

I actually don't even agree with the current 6 character password requirement.

chrismurphy
12th February 2015, 06:49 AM
mitr has been tidying up my FESCo ticket's formatting and added keyword: meeting
I take that as a good sign they will discuss this issue as requested.

Agreed, and I appreciate that you opened the ticket. Instead of word fountaining all over the place I should have just done that much earlier on when it was merely a 40 email thread issue. The ticket is exactly the right way to have handled this, and it's a much better diffuser than arguing could hope to be.

lsatenstein
15th February 2015, 08:05 AM
From the virtual terminal mode, I can force the password to be a single letter, and for normal (standard) user, to not even have a password. I can also force a new password on the next logon

antikythera
11th March 2015, 04:23 PM
The amusing thing is you can still set a ridiculously easy to break password even with the new restrictions active, for example:

incorrect123#

and that was attempted on root user account. Of course I have changed it before proceeding further. I just wanted to see how simple a password could be set for the sake of it on my VM Workstation F22 Alpha-3 installation.

chrismurphy
12th March 2015, 03:48 AM
The amusing thing is you can still set a ridiculously easy to break password even with the new restrictions active, for example:

Right, very weak passwords are disallowed but weak ones are permitted. The original point of the change was to only allow strong passwords, which if we were honest about it would mean proscribing passwords of less than ~25 characters. Which, in a schadenfreude sort of way I actually support because so many people would get P.O.'d it would make it abundantly clear how unworkable it is when it's made purposeful. But might makes right.

Anyway, it doesn't matter for Fedora 22, FESCo resolved last week to revert the "double-done" behavior and is now a beta blocker. Stay tuned for redux version, Fedora 23.

* #1412 anaconda password change is causing consternation among the user
community please review this policy decision (ajax, 18:24:10)
* AGREED: FESCo would like anaconda to turn back on the "double-done"
option for Fedora 22. Better solutions should be investigated for
F23. (ajax, 18:43:33)
https://www.marc.info/?l=fedora-devel-list&m=142549664827094&w=1