Anaconda 22.17+ enforces "good" passwords

Fri Feb 13 21:42:09 UTC 2015

On Fri, Feb 13, 2015 at 7:57 AM, Eric H. Christensen
<sparks at fedoraproject.org> wrote:
> -----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 goal of the brute force attack is to gain access, quickly. So the
strategy is always changing on both sides. What's true a few years ago
isn't necessarily true today.

http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/

I think it's much more likely a user has a 2, 3, or possibly a 4 word
password based on dictionary words, than truly random 8 using all
available ASCII characters. I'd expect at least 2 word combinations
from a dictionary to be attempted before random 8, and probably 3 word
combinations are.

Diceware is recommending 5 word passphrases as the minimum. I just
don't see that being accepted by users for a device. Sure for Twitter
but the context and consequences are totally different.

> 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.

a. The contra argument is that software engineers are dumb, they
should design this stuff better instead of dumping more complexity
onto the user. Ergo, be careful with flinging ad hominem attacks. Once
they're in bounds, the monkey on the other side of the debate is just
as full of crap.

b. Your example are bad ones. The installer doesn't mandate encrypted
volumes, and only encrypted volumes protect against your examples. A
stronger user or root password does exactly nothing. It doesn't alter
the time it takes me to own your data by even 1 second.

> 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.

Or you can lead by example with your own bad ideas into your product.
I have examples of this in Fedora if you ask.

But your style of debate above is sloppy, it contains no facts, it's
hand waiving and glittering generalities. I'll take on your disk
encryption non-suggestion from earlier since that's still peripherally
on topic:

OS X simply does it loads better than anyone. It can be opted into at
any time, post-install. Click two buttons and conversion begins. The
system can continue to be used, put to sleep, or even rebooted. The
user login is tied to unlocking the volume. This makes it more likely
the user will use disk encryption, only one password to know. It also
means the singular location for changing user password means disk
unlocking password is updated at the same time, the old password will
not unlock the volume. Further it means adding users causes no change
in UI from a non-encrypted system.

Linux: Well, we know how it works, it it's not like this. It's
viciously user hostile in comparison. It's in strictly in the realm
for sysadmin, esoteric level knowledge to manage this at all.

So give up the cave man style debate tactic. "Windows bad! UGHH! Mac
bad! UGHH!" isn't exactly convincing to any of my house plants, or me.

> 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.

Do you not see how your password policy defend hinges on grandiose
assumptions? I have many devices lying around without any information
on them, they're used strictly for testing, so there isn't anything
but an OS and some cache files for ycombinator and cnn, BFD. Oh but I
need to use strong passwords because someone ELSE might be an idiot
and have sensitive information on their laptop. So you are drawing me
into becoming responsible for other people's behavior too. Everyone is
baby sitting users who don't give a crap.

But let's say you're right, you thus far haven't argued for mandatory
disk encryption, which is really the only way to solve the problems
you keep using as examples. And yet it's a good thing you aren't
arguing for mandatory disk encryption because that UX is such complete
utter shit on Linux right now it is a Do Not Pass Go scenario. It
could never happen.

Meanwhile over on OS X, Apple is quite well situated for the next
version of the OS to default to disk encryption enabled, and the
user's workflow won't be impacted at all.

But I agree passwords are rubbish and solving that problem is one of
the Holy Grails. But this doesn't mean forcing users is better than
getting their compliance voluntarily.

Do you really think it'll go over well that Fedora *forces* users to
do something other platforms don't? I don't think there's an award for
this waiting.

>
>> 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.

I really hate it when people say to enable security features by
default. It's just really short sighted.

See how two can play that game? Do better.

First, sshd is not a security feature, it's a remote connection
service and increases the attack surface. Disable that. It has a lower
burden on more people, and it's also an expected burden for anyone
come from other enterprise cultures. The idea a Windows Server would
have remote services enabled by default? I think most any hard core
Windows sysadmin who also doesn't make bad excuses for Microsoft would
admit this could be a liability lawsuit waiting to happen if they were
to do that. That's how bad an idea it is.

And stronger password requirements is not a security feature, it's an
imposition.

>People don't want to have to go through their system changing switches and adding configuration just to have a secure system.

I honestly have no idea what you're talking about. Users can have
stronger passwords if they want to opt into this, at any time. Force
is not required. Flipping switches not required.

>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.

Users expect their system to be secure by default, meanwhile sshd is
enabled by default on Fedora 21 Server. Can you honestly not connect
the dots here? The very thing that's enabled by default is the very
thing being held up as the #1 reason why stronger passwords are needed
by default. If that service is disabled, a massive bulk of the
argument for stronger login passwords at install time is reduced.

Further, weak passwords are immediately, visually communicated in the
installer UI. The user always has this information available to them.

Meanwhile, the fact sshd is enabled is not ever communicated in the
installer UI. The user lacks this information.

But what you're saying is, it's the user that's the problem? The user
has perfect information of the former, not the later, yet it's the
former that needs enhancement? What?

Even if I accept the absurdity of full disclosure needing more
enhancement vs no disclosure, it means you don't trust the user. If
you trusted the user, simply informing them would be enough. But
informing them isn't enough, you have to force them. Therefore it's
clear they aren't trusted. If they aren't trusted, then why do you
trust they know the risk behind sshd enabled by default?

-- 
Chris Murphy