Attack vectors...

The difference is "can the private key (something you have) be copied?"

PKI hardware token: No.
File on notebook: Yes.

A PKI key on its own as a file on a harddrive is equal to a really complex password. So complex that you can't remember it so it is written down.

So, you encrypt the private encryption key with a passphrase. You have now put a password on your password.

If the key can be copied, then it does not subscribe to something you have being unique. A passphrase can be copied, so it is also not unique. The combination of the two are not unique.

Malware can attack a file on notebook and steal keystrokes for a passphrase.

For PKI hardware, data is sent to the token itself where the token (using it's own processor) encrypts/signs the data with the private key. The private key cannot be copied/read off the token. The private key can only be generated/used/erased via API calls to the hardware.

PKI USB tokens are basically smart card readers with a smart card permanently attached.

On 12/01/16 11:07, Morgan Blackthorne wrote:
I guess I'm not seeing much of a distinction between someone knowing
your password and someone knowing the passphrase on your key. If you
have a passphrase set, having a copy of the key does you no good without
the passphrase. But there's a pretty equivalent concern about someone
having both pieces of that equation vs. a normal password. Now something
like an OTP setup is a different story.

I agree with the enforcement perspective on keys; I wish SSH had a way
to flag whether or not a passphrase was enabled for a key and then
control restrictions on the server side as to what accounts are
whitelisted for automation vs. normal users where a passphrase is
enforced. But at the end of the day I'm unconvinced that a key is any
less secure than a password, as long as you have a passphrase configured.

On Thu, Dec 1, 2016 at 10:54 AM, Robert Hajime Lanning
<lann...@lanning.cc <mailto:lann...@lanning.cc>> wrote:

    Requiring a passphrase on your private key is not enforceable.

    And the key can be duplicated. So if someone has a copy of your key
    and gets/guesses your passphrase, you won't know they have access.

    Having the private key generated on a PKI hardware token that
    *enforces* a PIN/passphrase to access, covers those bases.

    On Dec 1, 2016, Morgan Blackthorne <mor...@windsofstorm.net
    <mailto:mor...@windsofstorm.net>> wrote:

        If you have a passphrase on your private key (as one should),
        would that not be considered something you know as well?

        On Thu, Dec 1, 2016 at 10:34 AM, Robert Hajime Lanning
        <lann...@lanning.cc <mailto:lann...@lanning.cc>> wrote:

            I have only implemented RSA, but I will be doing a bit of
            research on this topic shortly.

            For my current job we'll be needing MFA for a secure
            environment, in the next couple of months. They won't be
            able to afford RSA.

            But I do need to note that PKI key+Duo is not MFA.
            (Something you have + Something you have)

            MFA is Multi Factor Authentication and is defined as: (pick
            2+ separate items)

            1) Something you know (password/PIN not written down)
            2) Something you have (device that can not be copied, RSA
            fob, PKI hardware token/smart card...)
            3) Something you are (biometrics)

            RSA is fob + PIN.

            My current plan is a PKI hardware token that requires a
            PIN/passcode to unlock the token to use the private key
            contained within. The key pair is generated on the token and
            the private key cannot be copied off the token.

            Ssh and openvpn clients support PKCS#11 for PKI hardware.


            On Dec 1, 2016, Morgan Blackthorne <mor...@windsofstorm.net
            <mailto:mor...@windsofstorm.net>> wrote:

                I'm an end-user of Duo at the day job and relatively
                happy with it. Was not involved in the setup, though.
                OTOH I remember someone in #lopsa saying they had
                problems with them and had been unhappy. Can't remember
                who or why offhand, hopefully they'll chime in on this
                thread.

                I will note that the most common problem with Duo that
                I've personally seen is when folks have it configured to
                give them a phone call instead of running the app and
                getting a push notification. In our setup, to access the
                windows jumpbox we start an RDP session, and after
                normal user auth, it then triggers a Duo challenge. But
                the phone call setting seems to get delayed enough that
                the RDP session fails with a network policy error.
                People adjusting their user config with push
                notifications works better. I have not looked into
                seeing if you can just ! blanket disable that o! ption,
                but it seems a bit odd that they offer that as a service
                when it doesn't work; then again, we may have a more
                aggressive timeout policy on the Duo portion than is
                recommended. Again, wasn't involved in the setup as it
                predated me, so I'm not sure.

                I know it also works with Linux boxes and that's on my
                list to check out, just haven't gotten to it yet. We'd
                likely only enable it on nodes with public IPs that have
                SSH listening/allowed, so it has been low on my priority
                list.

                Duo is also apparently free depending on how many
                users/devices you have, whereas last time I heard about
                the RSA setup, it was very expensive. I'm planning on
                adding Duo support to my personal AWS Linux nodes for
                SSH (so key+MFA auth, no passwords allowed).

                On W! ed, Nov 30, 2016 at 10:31 AM, Kyle Stewart
                <_kylestew...@outlook.com
                <mailto:_kylestew...@outlook.com>> wrote:

                    Hi all, hope this email finds everyone well. We're
                    looking into setting up two-factor authentication at
                    my company for a 2017 project and I'm in the "Let's
                    get the lay of the land" phase. Right now it seems
                    like Duo is making big headway in this market, but
                    I've heard good things about RSA as well. I'd love
                    to get some first-hand feedback from people who have
                    used these types of 2FA solutions who aren't sales
                    people :)


                    Overall I get what 2FA/MFA does, but I'm blurry on
                    how it gets implemented - at face value I'm very
                    interested in Duo so if anyone has experience with
                    Duo and setting it up (preferably alongside Palo
                    Alto's and GlobalProtect) that'd be fantastic.


                    Thanks in advance!


--
Mr. Flibble
King of the Potato People
http://www.linkedin.com/in/RobertLanning
_______________________________________________
Discuss mailing list
Discuss@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/

Reply via email to