two factor authentication

[Frank Cusack]

On July 23, 2006 8:57:21 AM +0000 Jefferson Ogata <Jefferson.Ogata at noaa.gov> wrote:
> 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.

True, my original statement was misleading/incorrect.

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

Don't make me laugh.  A "management entity" is likely only to be concerned
about 2-factor auth because of input from internal IT (and then just as
likely to be ignored as not) or from a 3rd-party audit, not because of
experience with what 2-factor means and what it achieves.

I do disagree with you on whether or not a smartcard is 2 factor ... ok
techically yes, if you can get the key out of it, then the other factor
is just shine, but at what cost?  For the typical threat that has to be
protected against, a smartcard is sufficiently 2-factor.

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

I answered that twice: PAM/BSDAUTH with the correct backends, or publickey
with smartcards.  And to repeat myself, in the case where you can't change
sshd (say sshd on a router) then as long as you can do RADIUS you can
generally get multifactor auth via OTP tokens.  I'm quite surprised that
you would misread the smartcard part of my answer as trying to wrangle out
of the question.

It seems quite obvious how to have sshd do n-factor authentication in the
way the OP suggested: modify the code to require this.  I believe there
are already patches out there to do just that.  I suggested ways to do
this without requiring changes to sshd.

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

The intruder can easily determine it from observation.

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

Well, it often does.

-frank