de-peering for security sake

Sun Dec 27 04:35:19 UTC 2015

Owen you misunderstood what two factor is about. It is not practical to
brute force the key file. Nor is it practical to brute force a good
passphrase or password. Both have sufficient strength to withstand attack.

But two factor is about having two things that needs to be broken. The key
can be stolen, but the thief needs the password. The password can be
stolen, but the thief needs the key. He needs both.

SSH password + key file is accepted as two factor by PCI DSS auditors, so
yes it is in fact two factor.

But it is weak two factor because the key file is too easily stolen. NOT
because the key file can be brute forced. Nor because hypothetically
someone could memorize the content of the key file.

It is also weak because the key file can be duplicated. Note it does not
stop being two factor because of this, but stronger hardware based two
factor systems usually come with the property that it is very hard to
duplicate the key. Other examples of a two factor system were the key is
easy to duplicate is credit card with magnetic strip + pin. Example where
it is hard to duplicate is credit card with chip + pin. Both are examples
of where the password (the pin) is actually very weak, but it is still two
factor.

Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in
fact have a strength equal to 1024 bits entropy. It was considered equal to
about 128 bit of entropy, but is believed to be weaker now. I am using ECC
ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people
with tin foil hats believe we should stay away from NIST altogether. Unless
someone breaks the crypto, you are NOT going to brute force that key.

Yes I get your argument, you are saying break the key and you won't need
the password, but a) you can't actually break the key before the universe
ends, b) it is still two factor, just a extremely tiny in the academic
sense little bit weaker two factor. All crypto based two factor systems
suffers from the possibility that one could break the crypto and possibly
escape the need to know one or even both factors. But Owen - come one -
this silly argument pales and is so infinite insignificant to the real
problem with the ssh key two factor system, which is that the key is easily
stolen and duplicated and there is no way to check the quality of the
password (users might even change the key password to NO password).

Regards,

Baldur

On 27 December 2015 at 03:37, Owen DeLong <owen at delong.com> wrote:

>
> > 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
>
>