two factor authentication

[Frank Cusack]

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.

> 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.  Even when it is strong, this is generally considered
incovenient by users compared to a hardware token alone.

>> You are correct, for files on disk.  But publickey can also be used
>> with smartcards and via control of authorized_keys or using X.509
>> (there's a patch for that) you can restrict to keys known to be
>> protected by a pin/passphrase.
>
> How?

With controlled authorized_keys (equivalently with X.509) you only allow
keys that are on a smartcard.

-frank