[186644] in North American Network Operators' Group
Re: de-peering for security sake
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Sat Dec 26 18:46:04 2015
X-Original-To: nanog@nanog.org
To: Matthew Petach <mpetach@netflight.com>
From: Valdis.Kletnieks@vt.edu
In-Reply-To: <CAEmG1=qXi4Qq=Othy-dVD_94hy5HHee2R=b1=pPO9kVy0oLYFg@mail.gmail.com>
Date: Sat, 26 Dec 2015 18:45:53 -0500
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--==_Exmh_1451173553_10192P
Content-Type: text/plain; charset=us-ascii
On Sat, 26 Dec 2015 12:50:27 -0800, Matthew Petach said:
> No, the difference is that a passphrase works
> in conjunction with the private key, which is
> the "something you have" vs the "something
> you know" in two-factor authentication.
>
> With password authentication, there's only a
> single solution space for the attacker to
> sift through; with private key authentication,
> unless you're sloppy about securing your
> private key, there's two massive solution spaces
> for the attacker to sift through to find the unique
> point of intersection.
Actually, to be pedantic (and this is crypto, where failure to be pedantic
can be fatal), the online attacker still has only one large space to search
through. The private key you have on disk isn't the private key you
present to the remote server - the passphrase is used to convert from
one to the other.
(Hint: Consider the case of an ssh key generated without a passphrase.
Yes, there's valid reasons for doing this, such as allowing an ssh from
within a cronjob or other place where providing a passphrase is difficult.
And yes, if you do this, you should be securing it at the server end to
only allow that key to invoke the one command it was intended to, by using
the 'command="/your/one/command/here" option in authorized_keys)
> unless you're sloppy about securing your private key, there's two massive
> solution spaces for the attacker to sift through to find the unique point of
> intersection.
Actually, you have that backwards. The attacker only has 2 solution
spaces if you *have* been sloppy and your private key is captured.
The passphrase only helps if your private key on disk is captured - the
length of it determines how many possible on-the-wire private keys could
correspond to that on-disk copy. Just remember that if they captured that,
they almost certainly also captured your known_hosts file - you *did* hash
that, right? :)
And of course, nothing hardens it like an iptables rule that only accepts
inbound port 22 (or whatever you chose) to only address space you *expect*
to see inbound ssh from. :)
--==_Exmh_1451173553_10192P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Exmh version 2.5 07/13/2001
iQIVAwUBVn8msQdmEQWDXROgAQJkkRAAuKXbaWArEVSoUNd48Z8z7t9q7H+lLp0e
WYjf9+xjuuP3EAIG6Yh1U97T+Q2J1dl524MkC1/xl2J1NjIjPIekmQ7JQCZCVKic
KbCUURx3Dnx/u4Dk3Q8ad02Jo1zmVVoYs2o0latbJ1LeVsoYgHWAkC8Ntw0vAann
Lu3AComA/j01qBh3+ZA7tJoV0arNkOMMvelMtyUJDkB53lDZ4h9zFeJnSMaFMtKD
Zycqk8Ig0Jo+J+zpG/mcn5l4Ms05Vff2E16XUqPnZMZxbS/3JvOPbkwib61kDNKS
dUr5+Lz5gkijZPfFaKCce+6Pt5IYc5kntFlhjxO+kORCsm8iuqhtNKvRQJd1mWZU
IzoPkQiCfeNsgQV5w9wqJoKs9JBy56Z+t9cGIaMnnzu8RaYdqFX1cIolNoYC2Nqg
6s46HOTqViy8omvPm9GbHHeUy5gSudEIxBB3DPeQhwJBHeipVXNAiayp2ssBx7gh
q96iXajMoodx7+JL5Bt5C4jyDRhhomYyHpCVHOYRAS6VfzPAyjBILzffNhSoDzzA
6wvPhoHETbSI2Mo8jbeKOpP/62Pd6HCPTrBxcSrqy4CCMmx/wAvq+Dx3UXfa433U
V+GCdindASoe4oiNxtRNV6TAuGCxXvDnNYmGa0QPdlYEujkeU8iPsG8gWhdwyKAZ
NqMk213o1hY=
=XYSD
-----END PGP SIGNATURE-----
--==_Exmh_1451173553_10192P--
