Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SSH multi factor authentication
4 views
Skip to first unread message
Bruce F Bading
Jul 3, 2016, 10:33:51 PM7/3/16
to
There has been some good discussion around our IBM security team as to what
actually constitutes SSH multi factor authentication. There are 2 options
being discussed.
One, the Google Authenticator (OTP authentication).
Two, Public/Private key authentication (pubkeyauthentication = yes) which
supports pass phrase private key authentication.
Which of these is considered multi-factor authentication and can you give a
brief response? There are different opinions here and your opinion is
greatly appreciated.
Sincerely,
Bruce F. Bading
Senior Security Consultant
IBM Systems and Technology Group
830-237-6851
bad...@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!
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Stephen Harris
Jul 3, 2016, 10:55:23 PM7/3/16
to
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
> One, the Google Authenticator (OTP authentication).
have").
A combination of Google Authenticator _and_ password is 2FA. This is
easy to do with PAM.
> Two, Public/Private key authentication (pubkeyauthentication = yes) which
> supports pass phrase private key authentication.
Unfortunately this can't be enforced at the server; it's client side.
That's because the client could _remove_ the passphrase and reduce
it to "something you have". The server can't tell the difference.
So, from a controls perspective, you have to assume "single factor".
--
rgds
Stephen
Damien Miller
Jul 4, 2016, 2:05:24 AM7/4/16
to
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
> 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.
> > 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.
"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
Bruce F Bading
Jul 7, 2016, 10:03:17 AM7/7/16
to
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.
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
bad...@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!
Nico Kadel-Garcia
Jul 10, 2016, 11:33:43 AM7/10/16
to
On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading <bad...@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
>
> 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.
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.
Nico Kadel-Garcia
Jul 10, 2016, 11:33:55 AM7/10/16
to
On Sat, Jul 9, 2016 at 12:00 PM, Ben Lindstrom <mou...@eviladmin.org> wrote:
> We've all written horrible stuff to satisfy business requirements. Our
> universe, as admins,
> is scattered with many "yet another tool" or "yet another set of packages"
> to maintain for
> security or for our users to do their jobs.
Ben, I'm not trying to say it's not wise and sensible to go write a
non-standard, unsupported, and potentially root access destabilizing
non-standard workaround to shove user keys in a separate, locked,
down, root owned repository managed by someone other than the
individual user.
Actually, come to to think of it, I am saying it's an idea that many
admins do reject and should reject.. It's easy to do at first glance.
But taking manual control of sshd_config can be fragile, and can
breadk restarts of sshd. I don't recommend it for the faint-hearted
and those without test environments with local console access.
> So if the above is a requirement for your fictional admin then a tool will
> need to be written.
> And OpenSSH has already provided the means today by which it can easily
> integrate in.
Yes, you can hand modify or plug in a wrapper to modify sshd_config
and try to keep it consistent with OpenSSH release changes. It's
sometimes proven a finicky task.
> However, I would hope that it is a well written tool, and it can be shared
> with the community
> so it doesn't become a one-off burden.
Me, too. I haven't noticed any good ones. Even the chef "openssh"
cookbook doesn't have good default options for the different OpenSSH
variants, and tends to screw up SFTP settings if you use the cookbook.
> Anyways, the question still boils down to is Google Authenticator +
> Authorized Keys (with or
> without password) 2FA. And honestly I'm going to have to state it is 2FA in
> both cases.
> The argument is simple. If I use a password management tool (that requires
> me to unlock
> it with a different password) that auto fills in my Blizzard Battle.net
> login/password then I use
> the Blizzard's authenticator and type in the random code do I have 2FA?
I agree with this argument.
> Clearly, I've not typed my password. I may NOT EVEN KNOW my password (which
> is true
> in this case as it is a nasty auto-generated beast =). So it is basically
> the same as the
> 2048bit RSA authorized key I use in SSH. I use a password to decrypt
> access,
> but I only really possess both as I don't have them memorized.
> To complete the comparison I can write myself a password manager that
> doesn't require
> me to unlock (e.g. most "remember my password" crap in browsers). So the
> fact it is if
> my password is protected or not doesn't change my knowledge (or lack of) of
> the
> password.
This is the kind of thing I really, really don't recommend for the
faint of heart or the wise of maintenance. This sort of trick quickly
leds to the infamous XKCD "automation" chart, shown at
https://xkcd.com/1319/ .
> The same goes for RSA keys. Someone can steal my password manager, hack it,
> and
> gain access. Just like they could steal steal my RSA keys off my laptop.
>
>
> Ben
People *do* steal private SSH keys and other keys off computers, both
laptops and servers, all the time. I've certainly done it as a proof
of concept.
The last time, it was a "Linux architect" who erected an SSH tunnel
between servers at work and his home machine, with unencrypted SSH
private keys stored in his home direcotry on ech end, and published on
NFS shares. I was pretty shocked, but that kind of thing is not that
unusual. Keys get stolen by this kind of silliness *all the time*.
> We've all written horrible stuff to satisfy business requirements. Our
> universe, as admins,
> is scattered with many "yet another tool" or "yet another set of packages"
> to maintain for
> security or for our users to do their jobs.
Ben, I'm not trying to say it's not wise and sensible to go write a
non-standard, unsupported, and potentially root access destabilizing
non-standard workaround to shove user keys in a separate, locked,
down, root owned repository managed by someone other than the
individual user.
Actually, come to to think of it, I am saying it's an idea that many
admins do reject and should reject.. It's easy to do at first glance.
But taking manual control of sshd_config can be fragile, and can
breadk restarts of sshd. I don't recommend it for the faint-hearted
and those without test environments with local console access.
> So if the above is a requirement for your fictional admin then a tool will
> need to be written.
> And OpenSSH has already provided the means today by which it can easily
> integrate in.
Yes, you can hand modify or plug in a wrapper to modify sshd_config
and try to keep it consistent with OpenSSH release changes. It's
sometimes proven a finicky task.
> However, I would hope that it is a well written tool, and it can be shared
> with the community
> so it doesn't become a one-off burden.
Me, too. I haven't noticed any good ones. Even the chef "openssh"
cookbook doesn't have good default options for the different OpenSSH
variants, and tends to screw up SFTP settings if you use the cookbook.
> Anyways, the question still boils down to is Google Authenticator +
> Authorized Keys (with or
> without password) 2FA. And honestly I'm going to have to state it is 2FA in
> both cases.
> The argument is simple. If I use a password management tool (that requires
> me to unlock
> it with a different password) that auto fills in my Blizzard Battle.net
> login/password then I use
> the Blizzard's authenticator and type in the random code do I have 2FA?
I agree with this argument.
> Clearly, I've not typed my password. I may NOT EVEN KNOW my password (which
> is true
> in this case as it is a nasty auto-generated beast =). So it is basically
> the same as the
> 2048bit RSA authorized key I use in SSH. I use a password to decrypt
> access,
> but I only really possess both as I don't have them memorized.
> To complete the comparison I can write myself a password manager that
> doesn't require
> me to unlock (e.g. most "remember my password" crap in browsers). So the
> fact it is if
> my password is protected or not doesn't change my knowledge (or lack of) of
> the
> password.
This is the kind of thing I really, really don't recommend for the
faint of heart or the wise of maintenance. This sort of trick quickly
leds to the infamous XKCD "automation" chart, shown at
https://xkcd.com/1319/ .
> The same goes for RSA keys. Someone can steal my password manager, hack it,
> and
> gain access. Just like they could steal steal my RSA keys off my laptop.
>
>
> Ben
People *do* steal private SSH keys and other keys off computers, both
laptops and servers, all the time. I've certainly done it as a proof
of concept.
The last time, it was a "Linux architect" who erected an SSH tunnel
between servers at work and his home machine, with unencrypted SSH
private keys stored in his home direcotry on ech end, and published on
NFS shares. I was pretty shocked, but that kind of thing is not that
unusual. Keys get stolen by this kind of silliness *all the time*.
Ben Lindstrom
Jul 10, 2016, 11:34:56 AM7/10/16
to
Nico Kadel-Garcia wrote:
> On Thu, Jul 7, 2016 at 10:00 AM, Bruce F Bading<bad...@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.
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
Nico Kadel-Garcia
Jul 10, 2016, 11:34:57 AM7/10/16
to
On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom <mou...@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
> 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.
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
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.
Ben Lindstrom
Jul 10, 2016, 11:35:00 AM7/10/16
to
Nico Kadel-Garcia wrote:
> On Sat, Jul 9, 2016 at 10:30 AM, Ben Lindstrom<mou...@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.
configuration files, and would love
to just install the system and use it without having to lift a finger to
ever configure it. But sadly, life doesn't
permit us all that luxury. So it is a poor argument. Besides, anyone
maintaining a decent amount of
machines not using puppet, salt, ansible, or <insert new shiny
management tool here> is doing themselves
and their company a disservice.
> And maintaining
> those keys as the root user to lock these credentials may not be work
> most admins want to take on.
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."
So if the admin doesn't care about the restrictions you stated. Then they don't
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."
have to change the sshd_config. However, if they do then they are stepping out
from the defaults. Just like how those that want chroot sftp enabled need to
step out from the defaults. Just like those that need root access via authorizes
keys need to step out from the defaults.
>> 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.
We've all written horrible stuff to satisfy business requirements. Our
universe, as admins,
is scattered with many "yet another tool" or "yet another set of
packages" to maintain for
security or for our users to do their jobs.
universe, as admins,
is scattered with many "yet another tool" or "yet another set of
packages" to maintain for
security or for our users to do their jobs.
So if the above is a requirement for your fictional admin then a tool
will need to be written.
And OpenSSH has already provided the means today by which it can easily
integrate in.
will need to be written.
And OpenSSH has already provided the means today by which it can easily
integrate in.
However, I would hope that it is a well written tool, and it can be
shared with the community
so it doesn't become a one-off burden.
shared with the community
so it doesn't become a one-off burden.
Anyways, the question still boils down to is Google Authenticator +
Authorized Keys (with or
without password) 2FA. And honestly I'm going to have to state it is
2FA in both cases.
The argument is simple. If I use a password management tool (that
requires me to unlock
it with a different password) that auto fills in my Blizzard Battle.net
login/password then I use
the Blizzard's authenticator and type in the random code do I have 2FA?
Authorized Keys (with or
without password) 2FA. And honestly I'm going to have to state it is
2FA in both cases.
The argument is simple. If I use a password management tool (that
requires me to unlock
it with a different password) that auto fills in my Blizzard Battle.net
login/password then I use
the Blizzard's authenticator and type in the random code do I have 2FA?
Clearly, I've not typed my password. I may NOT EVEN KNOW my password
(which is true
in this case as it is a nasty auto-generated beast =). So it is
basically the same as the
2048bit RSA authorized key I use in SSH. I use a password to decrypt
access,
but I only really possess both as I don't have them memorized.
To complete the comparison I can write myself a password manager that
doesn't require
me to unlock (e.g. most "remember my password" crap in browsers). So
the fact it is if
my password is protected or not doesn't change my knowledge (or lack of)
of the
password.
(which is true
in this case as it is a nasty auto-generated beast =). So it is
basically the same as the
2048bit RSA authorized key I use in SSH. I use a password to decrypt
access,
but I only really possess both as I don't have them memorized.
To complete the comparison I can write myself a password manager that
doesn't require
me to unlock (e.g. most "remember my password" crap in browsers). So
the fact it is if
my password is protected or not doesn't change my knowledge (or lack of)
of the
password.
The same goes for RSA keys. Someone can steal my password manager, hack
it, and
gain access. Just like they could steal steal my RSA keys off my laptop.
Ben
it, and
gain access. Just like they could steal steal my RSA keys off my laptop.
Ben
0 new messages