On Dec 26, 2015, at 15:54 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On 27 December 2015 at 00:11, Owen DeLong <owen@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