[186679] in North American Network Operators' Group
Re: de-peering for security sake
daemon@ATHENA.MIT.EDU (Mike Hale)
Sun Dec 27 20:19:45 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <B19C6F9D-E43C-487C-BF26-209618CE3BE7@delong.com>
Date: Sun, 27 Dec 2015 17:19:42 -0800
From: Mike Hale <eyeronic.design@gmail.com>
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Also think of it from the perspective of the authenticating host.
That SSH connection relies *only* on the key for authentication. It
requires nothing else. How you protect that key is irrelevant. All
that matters is that the host is accepting a single form of
authentication. It's clearly single-factor.
You can call pseudo-multi-factor if you want. It's certainly better
than a shitty password. But it's not multi-factor by the generally
accepted definition (although I'd place it under 'something you have'
rather than the 'something you know' section).
On Sun, Dec 27, 2015 at 5:08 PM, Owen DeLong <owen@delong.com> wrote:
>
>> On Dec 27, 2015, at 14:33 , Baldur Norddahl <baldur.norddahl@gmail.com> =
wrote:
>>
>>
>>
>> On 27 December 2015 at 22:08, Owen DeLong <owen@delong.com <mailto:owen@=
delong.com>> wrote:
>> This is a bit of a tangent, really. The discussion was about authenticat=
ion factor
>> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
>> private key authentication as two-factor to bolster his claim that it wa=
s, in fact
>> two-factor, when it clearly isn=E2=80=99t actually two-factor as has bee=
n stated previously.
>>
>> I wanted to stay out of this, but Owen you are full of shit here. I am p=
ointing out that your homemade definition does not match up with what other=
s think two factor means. PCI DSS might be utter crap, but they are still m=
ore than "Owen DeLong and his personal opinion=E2=80=9D.
>
> Dude=E2=80=A6 It=E2=80=99s not just my opinion. Virtually every one else =
who chimed in on the thread other than you backed my position on this.
>
>> You are utterly confused about the meaning about two factor. You apparen=
tly believe the magic words "two factor" is a statement about the security =
of a system, while it is in fact just a simple property. A property that ev=
en an inherently insecure and weak system can have.
>
> No, as I pointed out, you can have very weak security with two weak facto=
rs.
>
> However, the property two-factor means something and it=E2=80=99s not wha=
t you apparently think.
>
>> It is not, as you have said, about strengthen the search space of a cryp=
to key (just double the key length if you need that). In fact, many two fac=
tor systems do not use crypto keys at all. An example of such a non crypto =
based system is a credit card with magnetic strip plus pin. The magnetic st=
rip contains just the card number, which can also be read directly from the=
card and even memorized by the owner.
>
> Actually, the magnetic stripe contains quite a bit more than the card num=
ber, but that=E2=80=99s another tangent.
>
> I never said you had to have crypto for two-factor, nor did I say that tw=
o factor magically made things stronger.
>
>> We need two factor because if you have just one factor, say the password=
, the hacker will simply call the user and ask him to tell the password. An=
d the users will happily obligate. Experience shows this. On the other hand=
, if you give the users a single factor system with a physical token (a key=
), that gets stolen, misplaced or "borrowed" far too easily. Therefore indu=
stry standard is card + pin to enter a building (=3Dtwo factor). Secure pla=
ces require three factor (card + pin + biometric).
>
> Card+pin is an example of two factors=E2=80=A6 You _HAVE_ the card and yo=
u _KNOW_ the PIN.
>
> Password-encrypted Key, OTOH, is something you _KNOW_ and something else =
you _KNOW_. It=E2=80=99s not something you _HAVE_ or something you _ARE_.
>
> There are three generally accepted categories of Factors for authenticati=
on=E2=80=A6
>
> 1. Something you HAVE
> 2. Something you KNOW
> 3. Something you ARE
>
> In order to qualify as 2-factor, a system must require something from two=
of the categories. Two things from the same category do not qualify.
>
>> SSH keys are two factor because people do not in general memorize the ke=
y file. Because they do not, you can not gain access to the system with onl=
y what you know (=3Din your mind). Unless the user violated protocols and c=
hanged the passphrase to null, you can not gain access just by possession o=
f the key file. That is all that is required to name it two factor. That Ow=
en DeLong believes the system stinks does not change that at all.
>
> Something on disk counts as something you know. A private/public key pair=
is not something you HAVE because it=E2=80=99s not a physical object and i=
t=E2=80=99s certainly not something you ARE.
>
> It=E2=80=99s clearly in the something you KNOW category for all practical=
purposes, even if you don=E2=80=99t memorize it into your mind.
>
> Now, a private key in black box where you feed it encrypted stuff to be d=
ecrypted or decrypted stuff to be encrypted and you cannot extract the priv=
ate key, that could be something you HAVE.
> But at that point, it=E2=80=99s the black box that is the thing you have,=
not the key itself. The key in the box and the boxes ability to decrypt/en=
crypt using that key is merely a mechanism for proving
> that you have the correct black box.
>
>> Historically the banks used to depend on a system that is the same as ss=
h keys: certificate files you have on your computer to access the bank webs=
ite. That also is a two factor system. The users did not usually memorize t=
he content of the certificates. The system is weak because bad guys used ma=
lware to steal the certificate files and install key loggers to also get th=
e other factor, the password.
>
> Again, real two-factor authentication depends on factors from different c=
ategories above. The certificate, like it or not, whether you memorize it o=
r not, is something you KNOW, not something you HAVE.
>
> To qualify as something you HAVE, it has to be a unique physical token wi=
th some degree of difficulty in duplication. Some physical tokens are easie=
r to duplicate than others. Examples include keys for pin-tumbler locks.
> Even those come in varying degrees of difficulty (3, 5, or 7 pins, straig=
ht or spool pins, angled pin alignments, etc.)
>
>> In my country (Denmark) they decided hardware keys are still too expensi=
ve, so they developed a two factor system based on paper keys. You will get=
a piece of paper with a few hundred random numbers. When you log in, you a=
re asked to type one of the numbers in to prove that you are in possession =
of the key paper. The codes are just 6 digits and infinite weak if you beli=
eve them to be part of any crypto scheme. This system has also been broken =
because now bad guys ask the users to take pictures of the key paper to pro=
ve something, and the users happily do just that. Banks are still happy tho=
ugh, because the loss is less than the cost to ship hardware keys to everyo=
ne.
>
> Why not just use Google Authenticator (free App) with a unique series on =
people=E2=80=99s smartphones? I=E2=80=99m pretty sure smartphones are quite=
common in DK by now.
>
>> Only strong two factor systems are really resistant to the users defeati=
ng the system by doing stupid things. That does not mean that only strong t=
wo factor systems are two factor. That would be silly - Owen what would you=
then name weak and broken two factor systems? It is a property - nothing m=
ore.
>
> Correct. However, calling a system which depends on two =E2=80=9Cfactors=
=E2=80=9D from the same factor category doesn=E2=80=99t meet the requiremen=
ts of a two factor system.
>
> Password protected SSH key is all in the something you KNOW category. Esp=
ecially when you consider that you aren=E2=80=99t presenting the password a=
nd the key to the authenticator, you are using the password to unlock the k=
ey that is presented to the authenticator.
>
> (yes, I realize the key isn=E2=80=99t actually presented, it=E2=80=99s do=
ne differently involving using the key to encrypt a hash which can then be =
verified as correctly encrypted by decrypting with the public key, but that=
=E2=80=99s a technicality that isn=E2=80=99t really relevant here).
>
> Owen
>
--=20
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0