Anaconda 22.17+ enforces "good" passwords

[Eric H. Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Feb 12, 2015 at 05:09:56PM -0700, Chris Murphy wrote:
> I don't have an easy way to prove this, but in a millions+ attempt
> brute force attack, I find it difficult to believe that
> correcthorsebatterystaple is not attempted, but 6*T!MsjD is attempted.
> I had recently read that up to 100 character dictionary only word
> based passwords were routinely attempted in brute force attacks.

I have a really awesome white paper sitting on a hard drive around here somewhere that explains this perfectly.  It comes down to the math involved.  Assuming all characters are available, letters (upper case and lower), numbers, and symbols, creates a good number of available choices for each password character.  It turns out, however, that using more characters in your password, assuming just letters, is far better than using a shorter password with everything.  Combine both of these, long password with all available character sets, and you get a really difficult password to break.

The other problem is the use of dictionary words.  With the rainbow tables available out there most brute force attacks start as dictionary attacks.  So using a word from the dictionary can really be bad.  I used to run John on highly secured enterprise systems only to break a high percentage of the passwords in less than 90 seconds (looking directly at the password hashes, not trying to gain entry to the system which is a bit harder.

> I think the change improperly shifts burden to all users without
> respect to their use case, in a manner inconsistent with the device
> control they've come to expect: no password requirements at all on
> mobile devices, and very minimalist ones on Windows and OS X. I don't
> see how being an outliar in this area, even among Linux distros,
> helps.

Yeah, but users are dumb.  They think their use case is a computer sitting in their house and that with this they are fine.  And this works great until their house is broken into or they leave their backpack, with their computer inside, on the subway and only then do they realize (or maybe they don't) that their security could have been better.

Never never never look to Windows or OS X as a way to show how things should be.  These operating systems are horrible.  From my experience, Linux users typically see Linux as more secure because we have better code and we don't allow dumb things (or we used to not do dumb things anyway).  Sometimes you just have to lead by example instead of looking around and trying to built other people's bad ideas into your product.

Oh, I said above that live attacks are more difficult than ones specifically looking at password hashes.  I'll explain this part a bit as I think it shows where we can balance user and backend burden.  When I have a hash table I can pour over it, almost indefinitely, to try to break a password.  I generally cannot do this on a properly configured system because of rate limiting and maximum retries.  If a system only allows for three tries before the account is locked I will likely not be able to break the password using brute force but would rather require some intelligence information (and I always start with sports team names).

In the end, passwords are all rubbish and should be done away with.  What are the other options, though?  I suspect most people aren't using smartcards to log into their systems (or any other kind of multi-factor authentication).  Until these options become more in use we need to raise the bar for password use.  People are carrying around more sensitive infromation with them in their pockets and on their backs and by not properly securing their system they are just asking for trouble.

> Conclusion: I think the concerning services need to be disabled by
> default, and use OOB management to enable those services, since it's a
> long standing practice elsewhere. If we can do better than this, fine,
> but not by shifting the security burden.

I really hate it when people say to disable security features by default.  It's just really short sighted.  People don't want to have to go through their system changing switches and adding configuration just to have a secure system.  Users expect their system to be secure by default.  If it's too much work to secure their systems properly they will either lose interest or forget to check a box and then get into trouble later.  It's much easier to remove a security feature someone feels strongly about instead of trying to implement everything with the potential of forgetting something or the inability to properly test a particular functionality.

- -- Eric

- --------------------------------------------------
Eric "Sparks" Christensen
Red Hat, Inc - Product Security

sparks at redhat.com - sparks at fedoraproject.org
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQGcBAEBCgAGBQJU3hDbAAoJEB/kgVGp2CYvklQL/i3i2Vn3PszV96QzB8KAD+Sx
LdcXjymgXssC9AoTjA/9wXtLDf3DlcIXwCb3dur5wJVSVATIyoHAJhttaSunuLKd
9SIdVUZTxsIxTKhYFHuxCkoKfwUS4ywUNIO+qb5JWnKuJyyFc4dEn5FIgeQszO4k
yMkXpcEOyVLvFIrxbYPlN6p6hyWzE2paCNoCy9FlzGSZEOhXOBtWfMB8Ki0/u2Gj
L+G/NEm0Df6i4lt//LnJCT05OJLDyLU8/t8/49qr4sHPR/bCcm86XJxP7Y0raDre
jSux2SdU8JGBeLGqMSeAmmWPccmjIgTwca5yOuOlFy8aGWG3GScv6x8aKgtP72Me
qfRPEfu/Y+k5Mr6vkSTgjFTY9rTEMQDeMC68DQ1FeBI07ejy+hUSXkE7TtLNGtt1
EtmpcY/DGLnowEeYlXG1AbpBVrRclH5xM9AVd8mw+AFp5Im+mdm3wF4vdeli50A/
3OnDJhdsWWyk/xVyIZ3mk3K/TMqc8hUmwkfKqnkWsA==
=rZzP
-----END PGP SIGNATURE-----