openssh unix dev - Jul 2016 - SSH multi factor authentication

On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading <badingb at us.ibm.com>
wrote:
>
> Hi Gentlemen,
>
> Thank you both for your valued opinion.  I do however agree that public key
> authentication cannot be fully considered MFA as have 2 PCI QSAs I have
> spoken with.  This is because it is not enforceable server side.  Many
> things can affect client side security.
>
> It is distributable and not enforceable at a single point.
> The key can be regenerated or downloaded again and regenerated to remove
> the paraphrase making it single factor authentication.
It's not merely possible. It's popular, and nearly inevitable. And
unless you can enforce use of a designated public key on the server
side, for example by breaking ownership checks and making the file and
directories owned by root with user groupo access, or by
auto-replacing $HOME/.ssh/authorized_keys, well, the user can replace
the key at whim with their own insecure key.

And most users *will* follow the default ssh-keygen behavior and use
no passphrase whatsoever. That's been a problem since.... 1995, when
SSH-1 was first written by Tatu Ylonen.

I'd still like to see "ssh-keygen" require a command line flag to
allow blank passwords, instead of the current default behavior. But
when I've suggested it among users, they've explained their firm
rejection of it in impolite terms.
> Keystoke loggers can log the keystrokes to unlock the key and capture it in
> band on the client.
> RSA and OTP generated by google authenticator w/password authentication can
> occur out of band and since enforceable on the server side are much more
> difficult to breach.
>
> Again, I want to thank you both for your valued opinion and which everyone
> a very great day.
>
> Sincerely,
> Bruce F. Bading
> Senior Security Consultant
>
> IBM Systems and Technology Group
> 830-237-6851
> badingb at us.ibm.com
> member ISACA since 1985
>
>
> "United We Stand"
>
> For those with risk, your time to remediate is today.
> For those who have been breached, your time to remediate was yesterday!
>
>
>
> From:   Damien Miller <djm at mindrot.org>
> To:     Stephen Harris <lists at spuddy.org>
> Cc:     Bruce F Bading/Austin/IBM at IBMUS, openssh-unix-dev at mindrot.org
> Date:   07/04/2016 01:04 AM
> Subject:        Re: SSH multi factor authentication
>
>
>
> On Sun, 3 Jul 2016, Stephen Harris wrote:
>
>> On Sun, Jul 03, 2016 at 09:19:43PM -0500, Bruce F Bading wrote:
>> > One, the Google Authenticator (OTP authentication).
>>
>> On its own, this is not 2FA.  It's single factor ("something
you
>> have").
>>
>> A combination of Google Authenticator _and_ password is 2FA.  This is
>> easy to do with PAM.
>
> Agreed
>
>> > Two, Public/Private key authentication (pubkeyauthentication =
yes)
> which
>> > supports pass phrase private key authentication.
>>
>> This is 2FA in that you need the private key and the passphrase for it.
>
> I don't agree - being able to unlock a private key is just part of
> "possessing" it.
>
> OTOH publickey+password authentication could be considered 2FA. Ideally
> with the key rendered practically uncloneable by holding it on a token,
> etc.
>
> -d
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Nico Kadel-Garcia wrote:
> On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading<badingb at
us.ibm.com>  wrote:
>> Hi Gentlemen,
>>
>> Thank you both for your valued opinion.  I do however agree that public
key
>> authentication cannot be fully considered MFA as have 2 PCI QSAs I have
>> spoken with.  This is because it is not enforceable server side.  Many
>> things can affect client side security.
>>
>> It is distributable and not enforceable at a single point.
>> The key can be regenerated or downloaded again and regenerated to
remove
>> the paraphrase making it single factor authentication.
>
> It's not merely possible. It's popular, and nearly inevitable. And
> unless you can enforce use of a designated public key on the server
> side, for example by breaking ownership checks and making the file and
> directories owned by root with user groupo access, or by
> auto-replacing $HOME/.ssh/authorized_keys, well, the user can replace
> the key at whim with their own insecure key.
You'd do this by either moving the authorized_keys to another a root 
owned location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile 
/etc/ssh/keys/authorized_keys.%u).  Or you use "AuthorizedKeysCommand"
and put the keys into a "database" to reference them via a simple 
root-owned program.

Personally I'd use the AuthorizedKeysCommand for this setup as it would 
provide for a better programmatic way of managing keys.

- Ben

On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom <mouring at eviladmin.org>
wrote:
> You'd do this by either moving the authorized_keys to another a root
owned
> location using "AuthorizedKeysFile" (e.g. AuthorizedKeysFile
> /etc/ssh/keys/authorized_keys.%u).  Or you use
"AuthorizedKeysCommand" and
> put the keys into a "database" to reference them via a simple
root-owned
> program.
Yeah, that's doable. It's very rare, though. Many people prefer not to
touch the default sshd_config if they can avoid it. And maintaining
those keys as the root user to lock these credentials may not be work
most admins want to take on.
> Personally I'd use the AuthorizedKeysCommand for this setup as it would
> provide for a better programmatic way of managing keys.
>
> - Ben
Then you have to write, or activate and maintain, yet another tool.
Feasible, but not many folks consider it worth the work. I've *done*
things like that, way back with some "one-time password" tools I used
back in the remote 9600 baud modem era.