two factor authentication

[Jefferson Ogata]

On 2006-07-23 07:34, Frank Cusack wrote:
> On July 23, 2006 1:50:20 AM +0000 Jefferson Ogata
> <Jefferson.Ogata at noaa.gov> wrote:
>> On 2006-07-23 01:27, Frank Cusack wrote:
>>> On July 22, 2006 7:08:59 PM -0500 jacob martinson
>>> <martinson.jacob at gmail.com> wrote:
>>>> On 7/22/06, Frank Cusack <fcusack at fcusack.com> wrote:
>>>>> On July 22, 2006 12:15:07 PM -0500 jacob martinson
>>>>> <martinson.jacob at gmail.com> wrote:
>>>>>> Are there any plans on the table to add native support for two-factor
>>>>>> authentication, such as password *and* public key?
>>>>> You can already do that.  Public key is itself already 2-factor --
>>>>> something you know (the pin/passcode) and something you have (the
>>>>> device on which the public key resides).  Password, via PAM or
>>>>> BSDAUTH,
>>>>> allows any two factor device the host (server) system supports.
>>>>>
>>>> You can?  How can you configure ssh to require both successful
>>>> password authentication (via the underlying OS password verification
>>>> mechanisms) and public key auth before the user is allowed onto the
>>>> system?
>>>
>>> Sorry, I meant you can already do native 2-factor auth via publickey
>>> or via password alone.
>>
>> Calling public-key "2-factor" is just spin.
> 
> Not at all.
> 
>> 1. You can't force people to put a passphrase on their private key.
>>
>> 2. You can't keep people from storing the key in ssh-agent.
>>
>> 3. If the private key--the actual factor--is compromised, it doesn't
>> matter if someone originally had a passphrase on it.
> 
> None of those are correct in the case of smartcards, and ssh publickey
> auth is agnostic as to whether the publickey auth came from a smartcard
> or an on-disk (essentially single-factor) key.

Your original statement was that "public key is itself already
2-factor", which is generally untrue. The secret is the private key.
Compromise of the factor is compromise of the private key, plain and simple.

Public key using a smartcard with a passphrase, which is what you've
changed the topic to, is a much more specific (and expensive) strategy,
and I might grant that it technically involves two factors (though they
really are entangled), since the private key resides, by nature, on
separate media from the rest of the system, unlike public key auth in
general.

But you appear to be playing word games with respect to two-factor
authentication. A management entity that says, "you must use two-factor
auth" won't be charmed by your fancy footwork--if you convince them that
public keys with smartcards is two-factor auth, they'll say, "fine, then
you have to do three-factor auth".

The real question that it would be nice to see answered is how to get
sshd to do n-factor authentication, rather than quibbling over how many
factors are involved in some particular authentication strategy. This
would be addressing the spirit of the original question, not trying to
use semantics to get out of solving the problem.

>> Some time back I wrote a patch to allow sshd to require multiple
>> authentication passes to succeed, so, e.g. public key could be combined
>> with s/key to achieve something like two-factor without a smartcard;
>> here the thing you have is the piece of paper with the one-time
>> passwords written on it, and if it falls out of your pocket at the
>> convenience store, it presents no threat by itself because there's a
>> keypair somewhere that's also needed; conversely if your keypair is
>> compromised that doesn't give the intruder access to your pocket.
> 
> Unless you let the user generate the S/Key seed, in which case it will
> probably be weak.

It may--so what? The intruder doesn't automatically know what it is.

S/key is simply a convenient example because it is free and openssh
already supports it; someone is free to implement an OTP system that
relies on a list of random, unrelated, single-use passwords. The
specific implementation is irrelevant--the point is that OTP is a
distinct factor from publickey, by nature.

>   Even when it is strong, this is generally considered incovenient by users compared to a hardware token alone.

Yes, some people believe more security often means less convenience.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service