de-peering for security sake

Sat Dec 26 23:45:53 UTC 2015

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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151226/1f6a9588/attachment.sig>