[CentOS] Fedora change that will probably affect RHEL

[Chris Murphy]

On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml at etr-usa.com> wrote:

> Security is *always* opposed to convenience.

False. OS X by default runs only signed binaries, and if they come
from the App Store they run in a sandbox. User gains significant
security with this, and are completely unaware of it. There is no
inconvenience.

What is the inconvenience of encrypting your device compared to the
security? Zero vs a ton more secure (either when turned off and data
is at rest or a remote kill that makes it very fast to effectively
wipe all data)


> I’m still not seeing how it’s difficult to remember, securely record, type, or transcribe a password that will pass the new restrictions.  They’re on the mild side, as these things go.

I disagree to the point I'd stop using products based on such
restrictions. I will not participate in security theatre, other than
to be theatrically irritated.

I'm guessing you're not a tester or much of a home user. There are
many such people using OS X, Windows, and yes Fedora and likely
CentOS, where environments and use case preclude compulsory compliance
because the risk is managed in other ways.

And Apple and Microsoft have been working to kill login passwords for
a while. Google and Facebook too. No one likes them. And our trust in
them is diminishing. They are not long term tenable. Making longer
ones compulsory already causes companies who do so grief as people
complain vociferously about such policies.


> I have no strong feelings on the new libpwquality rules, exactly.  What I do feel strongly about is that there should be *some* reasonable minima that can’t easily be bypassed.

This idea that opt in is not sufficient demonstrates how archaic and
busted computer security is when you have to become coercive to
everyone regardless of use case to make it safe.

In any case, the complaint over on the Fedora proposal has been
sufficiently addressed, even though the details are still being worked
out. The gist is that the user will have informed consent, and will
opt in to better quality passwords. So they will essentially be told
a. the password they've proposed sucks, b. fairly clear information on
why it sucks, c. the option to change it or continue anyway.


> I don’t see why we can’t take some responsibility for this mess and try to build up some herd immunity.

Because there is no such thing when it comes to computers. Computers
with strong passphrases still sometimes get pwned, and at a much
higher rate than vaccines not working. Please stop with this hideously
bad analogy. Computers with NO passwords are often not ever getting
pwned for their entire lifetime, and those computers, a.k.a. mobile
devices, are used in public spaces, on public wifi, on public
networks. Anyone without vaccines in such proximity to illness would
definitely get sick. That doesn't happen with computers.

The environment has changed, and the old architectures and methods
aren't working the way they did. And somehow free open source software
has got to do better than it has been with security, because
proprietary systems are innovating more in this space right now, and
aren't passing the buck onto the user with this burden in the form of
stronger password requirements.

Besides, it's FOSS for a reason and people will opt out because
ultimately you can't make them do what you want. Apple and Microsoft
could possibly get away with it. I think their customers would become
foaming irate, however.


-- 
Chris Murphy