CentOS - Jul 2015 - Fedora change that will probably affect RHEL

On Thu, Jul 30, 2015 at 12:20 PM, Warren Young <wyml at etr-usa.com>
wrote:
> On Jul 29, 2015, at 5:40 PM, Chris Murphy <lists at
colorremedies.com> wrote:
>>
>> 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.
>
> You must not use OS X regularly, else you?d know there is plenty of
inconvenience in this policy.
Really, I must not, even though it's roughly 80/20 OS X to Fedora...

>  There?s a whole lot of good software that is both unsigned and not in the
App Store.  Examples:
Spare me. The fact it is imperfect is meaningless to the discussion.
The original argument was that security increase always cause user
inconvenience. That is not true. Millions of users using tens of
thousands of applications in an eco system they see no problem with,
unaware that those applications are code signed, and no concern at all
about the alternatives. Good for them, they're safer than without code
signing and their life has not been made inconvenient as a result.

That this needs to be expanded, made easier, made more open, so that
it's not just customers using proprietary software who benefit from
stronger security measures with minimal usability impact.

>
>> What is the inconvenience of encrypting your device compared to the
>> security?
>
> I can?t hook my iPad up to my PC and browse it as just another filesystem,
as I can with any other digital camera or MP3 player.  Apple must do this in
order to prevent sideloading malicious apps.
OK one of us must have the self control to stop, because your
arguments are terrible and I'm losing patience.

What you just claimed, has nothing to do with encryption. It has
everything to do with Apple simply not treating their devices as mass
storage devices which they haven't done since forever - even without
encryption.

And Android is the same. Whether encrypted or not, it's not a mass
storage device, you can't mount the file system. It supports MTP,
whether encrypted or not. JFC....

>> I will not participate in security theatre
>
> Really?  You?re going to lay *that* card in this game?
>
> When you stretch words and phrases beyond their original meaning, they lose
shape and utility.
>
> 6-9 character password limits are *not* "security theatre?.
Ok well I consider passwords that keep the dog out and probably most
family members to be security theater.

No fail2ban, no firewall rules, sshd by default, challengeresponseauth
by default, and a 9 character (even random) passphrase, and that shit
is going to get busted into. Against a targeted attack by a botnet,
you need something stronger than a 9 character password, today. Let
alone 6 years from now.

Those other measures need to get better (PKA only, put it behind a
VPN). Not the password getting slightly longer.

ATMs and credit cards in the U.S. The weak link is the magnetic
stripe, not the 4 digit PIN. The enhancement for credit cards due this
year is not 5 or 6 digit PINs. It's EMV chips. And the end user will
be minimally affected in terms of usability, the security will be
vastly better than even if 5 or 6 digit PINs were employed and besides
no one would accept that anyway.

And that's where we are with computers and passwords.

> Meanwhile over here in CentOS land, you still see SSH password guessers
banging on every public IP that responds to port 22.  Why?  Because it still
occasionally works.  Increase the password strength minima, and this class of
worm, too, will quickly die out.
No they just get better, like they have been, at an exponential rate
compared to our ability to recall login passwords.


>
>> Computers with strong passphrases still sometimes get pwned
>
> The occasional failure of a prophylactic measure does not tell you that you
should discontinue its use.
>
>> and at a much higher rate than vaccines not working.
>
> I thought you threw out a 95% number for vaccine effectiveness above.  You
are saying that more than 5% of all computers with strong passphrases are
currently infected with something?  Prove it.

Define strong. Diceware puts the minimum for large botnet protection
at 5 word passphrases. 6 word passphrases for protection against a
government entity. Your idea of strong thus far is 9 characters which
seems to be b.s. today and certainly laughable in 6 years when we do
the autopsy on today's policy successes and failures.

> So your solution is to wait for unspecified innovations to come?  All these
problems will go away in the indefinite future, so we should do nothing now?
I did say disable sshd by default, and several other suggestions many
of which could be done right now. That you gloss over this and turn it
into this pile of crap leading questions is fairly disqualifying in
debate. Each suggestion has greater security efficacy than a 2-3
character increase in password length.


-- 
Chris Murphy

On 07/30/2015 12:35 PM, Chris Murphy wrote:
> No fail2ban, no firewall rules, sshd by default, challengeresponseauth
> by default,
ChallengeResponseAuth is not on by default, on Red Hat derived systems.  
I'm pretty sure that was already clarified, much earlier in this thread.
> and a 9 character (even random) passphrase, and that shit
> is going to get busted into. Against a targeted attack by a botnet,
> you need something stronger than a 9 character password, today. Let
> alone 6 years from now.
6 years from now, the maximum speed of guessing passwords against an ssh 
server will be exactly the same as it is today.  The server imposes 
delays on failure and maximum connection numbers.  With those 
mechanisms, the rate is constant.
> Diceware puts the minimum for large botnet protection
> at 5 word passphrases. 6 word passphrases for protection against a
> government entity. Your idea of strong thus far is 9 characters which
> seems to be b.s. today and certainly laughable in 6 years when we do
> the autopsy on today's policy successes and failures.
I've read your references to diceware here and earlier in this thread, 
and I'm pretty sure you don't understand it.  Their page makes the 
purpose clear: "Short passwords are OK for logging onto computer system 
that are programmed to detect multiple incorrect guesses and protect the 
stored passwords properly, but they are not safe for use with encryption 
systems."

Diceware is intended to help you generate passphrases that you will use 
to protect an encryption key, such that an offline attack against that 
passphrase is unfeasible.

You appear to be advocating for significantly longer passwords for 
authentication, but as diceware makes clear, online attacks are already 
mitigated by rate limits enforced by the server.  Offline attacks, such 
as diceware is intended to thwart, are only possible if the attacker has 
your password file.  In which case they already have root.  In which 
case they don't really need to crack your passwords.

So, unless I misread you, can we let this thread die out?

On Jul 30, 2015, at 4:27 PM, Gordon Messmer <gordon.messmer at gmail.com>
wrote:
> 
> On 07/30/2015 12:35 PM, Chris Murphy wrote:
>> No fail2ban, no firewall rules, sshd by default, challengeresponseauth
>> by default,
> 
> ChallengeResponseAuth is not on by default, on Red Hat derived systems. 
I'm pretty sure that was already clarified, much earlier in this thread.
I think Chris is using ?challenge response auth? as a synonym for ?everything
except public key auth? since CRA can be an umbrella auth method for just about
every type of authentication, via PAM.

At bottom, I blame OpenSSH for this confusion.  They should have named the pref
something else, like TunneledAuth or RFC4256Auth.

Then we could use the term ?challenge/response? in the narrow way I defined it
earlier in the thread.
>> Diceware puts the minimum for large botnet protection
>> at 5 word passphrases.
> 
> I've read your references to diceware here and earlier in this thread,
and I'm pretty sure you don't understand it.
I?ve only been talking about the online attack scenario, but Chris keeps wanting
to go back to the offline scenario.  Basically, he?s assuming attackers will
have a copy of /etc/shadow.
> Diceware is intended to help you generate passphrases that you will use to
protect an encryption key
It?s also useful on public web sites, since you don?t know if there might
someday be a SQL injection attack that can pull the users table, which may not
even be salted, much less run through a KDF.

Since that is not what this proposed Fedora change is trying to address, I don?t
see why we need to even be talking about Diceware in this thread.