[186647] in North American Network Operators' Group
Re: de-peering for security sake
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Dec 26 21:38:42 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPkb-7Cab3=2Xzmnx6+CJA0B7wBh-pfLOUXVEgFphCWetqfX4w@mail.gmail.com>
Date: Sat, 26 Dec 2015 18:37:36 -0800
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Dec 26, 2015, at 15:54 , Baldur Norddahl =
<baldur.norddahl@gmail.com> wrote:
>=20
> On 27 December 2015 at 00:11, Owen DeLong <owen@delong.com> wrote:
>=20
>> No=E2=80=A6 You are missing the point. Guessing a private key is =
roughly
>> equivalent to guessing a really long
>> pass phrase. There is no way that the server side can enforce =
password
>> protection of the private key
>> on the client side, so if you are assuming that public-key =
authentication
>> is two-factor, then you are
>> failing miserably.
>>=20
>=20
> The key approach is still better. Even if the password is 123456 the
> attacker is not going to get in, unless he somehow stole the key file.
Incorrect=E2=80=A6 It is possible the attacker could brute-force the key =
file.
A 1024 bit key is only as good as a ~256 character passphrase in terms =
of entropy.
If you are brute force or otherwise synthesizing the private key, you do =
not need
the passphrase for the on-disk key. As was pointed out elsewhere, the =
passphrase
for the key file only matters if you already stole the key file.
In terms of guessing the private key vs. guessing a suitably long pass =
phrase, the
difficulty is roughly equivalent.
> Technically it is two-factor even if the user made one of the factors
> really easy. And that might save the day if you have users that =
chooses bad
> passwords.
Technically it=E2=80=99s not two-factor and pretending it is is =
dangerous.
> The system is weak in that it is too easy to steal the key file. It is =
not
> unlikely that a user with sloppy passwords is also sloppy with his key =
file.
Right=E2=80=A6 No matter what you do it is virtually impossible to =
protect against sloppy
users.
This has been true for decades even before the internet with teenagers =
given house
keys.
> Too bad ssh does not generally support a challenge-response protocol =
to a
> write only hardware key device combined with server side passwords =
that can
> be checked against a blacklist.
There=E2=80=99s no reason that it can=E2=80=99t if you use PAM.
Owen
