Re: [gentoo-user] OpenSSH upgrade warning

[Alan McKinnon <alan.mckinnon@gmail.com>]

On 10/11/2015 17:58, Michael Orlitzky wrote:
> On 11/10/2015 10:30 AM, Alan McKinnon wrote:
>>> Maybe, but your argument isn't convincing. How am I better off doing it
>>> your way (what is your way)?
>>
>> The most common way is to disallow all remote logins as root. Admins log
>> in with their personal unpriv account using an ssh key. To become root
>> they must su or sudo -i with a password.
>>
>> Benefits: two factor auth using different mechanisms. Having the key or
>> the password is not enough to become root, an attacker must have both.
>>
>> Allowing root logins directly over the network is considered bad
>> practice, due to the "one mistake = you lose" aspect.
>>
> 
> It sounds good, but what sort of attack on my root password does the
> two-factor authentication prevent? Assume that I'm not an idiot and to
> brute-force my root password would take literally forever.
> 
> I'm weighing this against the complexity of adding separate accounts,
> making sure that *those* are secure, risking breakage of the sudoers
> file, granting someone the ability to brute force my SSH key password
> offline,...
> 
> All of the good attacks (shoot me, bribe me, steal the hardware, etc.)
> that I can think of work just fine against the two-factor auth. The only
> other way to get the root password is to be there when I transfer it
> from my brain to the terminal, in which case you have the SSH key, too.

I think you are approaching this problem from the wrong viewpoint. You
have to assume an attacker has vastly more resources to bear on the
problem than you have. Thanks to Amazon and the cloud, this is now a
very true reality. Brute force attacking a root password is nowhere near
as complex as the maths would lead you to believe; for one thing they
are decidedly not random. The fact is that they are heavily biased,
mostly due to 1) you need to be able to remember it and 2) you need to
be able to type it.

Humans have been proven to be very bad at coming up with passwords that
are truly good[1] and hard for computers to figure out. And our brains
and very very VERY good at convincing us that our latest dumb idea is
awesome. Are you really going to protect the mother lode (root password)
with a single system proven to be quite broken and deeply flawed by wetware?

Two factor auth is cheap (ssh-keygen and ssh-copy-id) and keys take the
human factor out of the first step. It's not security theatre nor cargo
culting, so why not use it and gain the benefits for minimal effort?

Complexity of separate accounts is a bit of a red herring. If your user
account is weak, I have to assume so is your root account - apart from
UID=0 there is no difference between them. Hopefully you use Puppet or
friends so you set up a decent template once and the system ensures it
stays that way. No having to check if user accounts really are still not
weak.

Finally the root password by it's nature is a shared secret between one
or more admins. On every system a boss has had me look after, I have
shown to my own satisfaction that it is the weak link. It has to exist,
it has to be known an it has to be communicated when it changes. Systems
designed to help make that process safe are themselves weak (such as a
GPG encrypted file protected by .... a never-changing shared password
that every admin knows!) Am I going to build a front line of defence
based on ssh keys? You betcha.

Alan

[1] Our bosses and auditors keep coming up with stupid ideas designed to
improve this but all they succeed in doing is causing the problem they
seek to solve. Such as rotating passwords, insisting on punctuation, no
repeating characters. In the real world all this does is invite *bad*
practices - people have to resort to this to get something that
satisfies the password policy and they can remember. And from there it's
a short step to Post-It-Note syndrome


-- 
Alan McKinnon
alan.mckinnon@gmail.com