de-peering for security sake

Sun Dec 27 02:37:36 UTC 2015

> On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> 
> On 27 December 2015 at 00:11, Owen DeLong <owen at delong.com> wrote:
> 
>> No… 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.
>> 
> 
> 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… 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’s 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… 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’s no reason that it can’t if you use PAM.

Owen