Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Dec 2015 08:27:45 +0100
From:      Terje Elde <terje@elde.net>
To:        "Michael B. Eichorn" <ike@michaeleichorn.com>
Cc:        Matthew Seaman <matthew@FreeBSD.org>, freebsd-questions@freebsd.org
Subject:   Re: best practice for locking down private jail?
Message-ID:  <EE872558-1B69-458C-A56C-F150637E1F63@elde.net>
In-Reply-To: <1449813845.30424.81.camel@michaeleichorn.com>
References:  <CACcSE1yQO8AjW9rpY%2Bd2p1-ArPbO4qKV0zcaCMyRhYEWLOpQGA@mail.gmail.com> <CACcSE1yqeXqd=mLJ-=aJGr0hXcUEE0v3MeiAty6e4cgpWF7D8g@mail.gmail.com> <20151203083926.72ad74db.freebsd@edvax.de> <565FFBDF.40907@FreeBSD.org> <B47F1A5D-AD1D-4A4C-AF63-5CF1C896E0A7@elde.net> <1449813845.30424.81.camel@michaeleichorn.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> On 11 Dec 2015, at 07:04, Michael B. Eichorn <ike@michaeleichorn.com> wrot=
e:
>=20
> I don't think that the keys are so weak that offline cracking is really
> that worrysome though. The key encryption method (AES-128-CBC) is
> beyond the abilties of non-nationstates to attack, and even then it is
> still deemed very unlikely.

True for the encryption algorithm, but people don't break algorithms, they b=
reak keys, and that's a very different situation.=20

Say for example that your password is "f", the attacker tries to guess it st=
arting from "a" and moving on from there. With offline checking, he'd have y=
our password in no time. With online checking - and a limit of three attempt=
s - he'd actually fail completely, despite the horribly bad password.=20

> Oh and if you are really concerned about password replays, there is
> opie. Or even key + password + opie + 2FA, or even key + 1 of the
> others. SSH is fancy!

There's also a patch for OpenSSH to support FIDO U2F floating around.=20

> I think most of the talk about key + password has been from the
> perspective of if a sysadmin needs to do both. If you can trust
> yourself to protect your keys you probably don't need to add password.
> But for the less-security minded users both is better, if only because
> it is hard to enforce encrypted keys.

Yeah, there's definitively a need for finding the right tradeoff, and what t=
hat is depends a lot on the situation.=20

There's probably also little point in going entirely overboard; if your mach=
ine is completely compromised, an attacker would gain access to your logged i=
n sessions, no matter how well you authenticate the session setup.=20


While on the topic of ssh, there's an argument to be made for being careful w=
ith users ~/.ssh/authorized_keys. If an attacker gains temporary access to a=
 system, it's often too easy to turn that into permanent access by slipping i=
n a key of his own.=20

There's a lot of ways to protect against that, such as having sshd look for k=
eys only in a place the users can't write, or running nightly checks and mai=
ling users about changes.=20

(First has issue with users loosing access to revoke keys, second has a dela=
y and only gives notification, not prevention).=20

Terje





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE872558-1B69-458C-A56C-F150637E1F63>