nanog mailing list archives
Re: de-peering for security sake
From: Owen DeLong <owen () delong com>
Date: Sat, 26 Dec 2015 18:37:36 -0800
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
Current thread:
- Re: de-peering for security sake, (continued)
- Re: de-peering for security sake Stephen Satchell (Dec 26)
- Re: de-peering for security sake Baldur Norddahl (Dec 26)
- Re: de-peering for security sake Mike Hammett (Dec 26)
- Re: de-peering for security sake Joe Abley (Dec 26)
- Re: de-peering for security sake William Waites (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 26)
- Re: de-peering for security sake Matthew Petach (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 26)
- Re: de-peering for security sake Valdis . Kletnieks (Dec 26)
- Re: de-peering for security sake Baldur Norddahl (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 26)
- Re: de-peering for security sake Baldur Norddahl (Dec 26)
- Re: de-peering for security sake Owen DeLong (Dec 27)
- Re: de-peering for security sake Valdis . Kletnieks (Dec 27)
- Re: de-peering for security sake Christopher Morrow (Dec 27)
- Re: de-peering for security sake Mike Hale (Dec 27)
- Re: de-peering for security sake Christopher Morrow (Dec 27)
- Re: de-peering for security sake Mike Hale (Dec 27)
- Re: de-peering for security sake Randy Bush (Dec 27)
- Re: de-peering for security sake Christopher Morrow (Dec 27)
- Re: de-peering for security sake Mike Hale (Dec 27)