Breaking off from the earlier bastion host thread to make it easier to
keep track of thread divergence...

Hot Diggety! Dan Foster was rumored to have written:
>
> I haven't looked at non-RSA two factor solutions lately, but a few
> years ago, I looked into all this for home use.

After some digging through my old notes from years ago, turns out it was
the CRYPTOCard product I'd looked at back then. For instance:

http://www.securehq.com/vendors.wml&sessionid=200132811363510950&vendorid=44

According to my original research, looked like most such 2FA (two-factor
authentication) solutions came in a minimum bundle of 5 or 10 user
starter kits. Typically around US $50 per 'football' (keychain fob) at
10 users. Per-seat cost is cheaper in volume. That's just for the
client-side physical hardware. You still need the server-side component
(and any administrative components as well as authentication components)
which usually costs extra.

So for a basic 10-seat setup, probably closer to about US $1000.

However, being curious... I talked with a veteran CISSP security
professional earlier today about non-RSA 2FA solutions with the aim of
using in a low-cost shop or for personal deployment (home, church, whatever).

It was a pretty good chat. He suggested that anyone willing to lay out
some money for 2FA but didn't want to go down the road of ridiculous
pricing might want to look at an interesting up-and-coming product
that's been around for several years: the YubiKey, made by Yubico in Sweden.

We extensively discussed the pros and cons, and I soon saw it from his
viewpoint: this was something he would be comfortable in recommending
for personal or SOHO type deployments, especially if the maintainer is
technically savvy and cost is a significant driver.

Now, a basic disclaimer: neither of us have actually deployed anything
utilizing this particular product. He is far more familiar with it,
having had come pretty close to actually buying it. Me? I'm just a
parrot at this stage, albeit an extremely interested Polly who wants his
AES-128 cracker. ;-) (And will be giving it a closer look for home use.)

In my environment (home use), several factors are paramount:

        - Reasonable longevity
        - Some OSS support preferred
        - Multiplatform support for at least Windows, Linux, and MacOS X
        - Reasonable pricing
        - Reasonable security design
        - Minimum of complex client-side software to be installed

Let me dump a few URLs that we discussed:

        YubiKey home page:

        http://www.yubico.com/products/yubikey/

        Steve Gibson of GRC Research (I know what some folks thinks
        about him, but at least he discussed the nitty gritty about this
        product...):

        http://www.grc.com/sn/sn-143.pdf

        (For the above link, some info on page 12, more technical
         details about the AES-128 hash algorithm and risk factors starting
         on page 18.)

        Review of the YubiKey:

        
http://www.readwriteweb.com/archives/yubikey_your_key_to_securing_the_web.php

        More information on the YubiKey:

        
http://wiki.yubico.com/wiki/index.php/Applications:Authoritize#Authoritize

        PAM module for YubiKey (good for at least Linux, maybe Solaris??):

        http://www.securixlive.com/yubipam/

        YubiKey and MacOS X client side support:

        
http://wiki.yubico.com/wiki/index.php/Applications:Mac_OS_Logon#Mac_OS_Logon

OK, with all that out of the way... the YubiKey is attractive for
several reasons:

        1) Pricing starts at $25/key for 1-9 keys, $20/key for 10-19, etc...

        At least 50% cheaper than RSA SecurID, CRYPTOCard, etc. One time
        cost, non-recurring.

        2) Server side component is affordable. He didn't have pricing
           but it was somewhere around US $200? Competition's price is
           generally $200-$500/server software.

        3) This is a USB key. You plug it into a USB port, and it
           autodetects as a USB keyboard, passing along the AES hash.

           USB support these days is fairly widespread.

        4) This is multiplatform, with client side support for the three
           major end user platforms. (Windows, Linux, MacOS X.)

        5) At least some part of this is open source, which means easier
           adaption for some platforms as well as longer-term support should
           the company ever go out of business.

        6) It stores at least one essential bit of information in NVRAM,
           but DOES NOT require a battery embedded in the key to function.
           It's USB bus-powered.

        7) It's good for up to 32,767 'sessions' (insertions into the host)
           before the key self-expires. You can have an unlimited number
           of hashes/passwords offered per session.

           Doing some basic math, you'd need to insert the key in the
           host 18 times a day, 365 days a year, for 5 years, before hitting
           the session limit. Seemed reasonable.

        8) I'm told that there's been a critical amount of groundswell
           support in the OSS community, which implies it works well
           with all the modern platforms (and likely some of the older ones).

        9) The most recent firmware as of 3 months ago apparently now
           supports both OTP (one-time password) mode by default, but if
           you press the button for several seconds, it will then let you
           enter a pre-configured static password.

           Could be handy if for some weird reason, the network is completely
           down and you can't reach any of the OTP auth servers. This is
           probably more useful for admin-type technical users or
           mission-critical users (e.g. network ops center type people).

        10) Not vulnerable to replay attacks. (This is what they mean by
            time-variant.)

I should point out a few things:

        - This does require installation of a client auth hook module on
          all platforms. Small, but has to be present. This is so the
          client host will know how to properly route the proffered auth data
          to an auth server.

        - The OTP auth server has to be network-connected (and
          functional) for all OTP auth requests. In other words, make
          sure your end-to-end infrastructure is robust! That would have
          had applied for any similar types of auth servers, too.

        - Being contact-based hardware, it *does* have physical
          limitations, mostly incurred from the number of insert/removal
          cycles. Your basic wear-and-tear, in other words. I'm not sure
          what you'd actually expect to get in real world usage, but would
          guess probably 3-5 years of moderate use?? I could be wrong.


Again, I should plainly state flat out that I have never deployed this
product, so it may or may not be as promising as it sounds. Real world
deployment experience from anyone else here would be most welcome. I
also have no relationship with Yubico or any VAR. In fact, I didn't hear
about this product for the first time until about 45 minutes ago. :)

But knowing the pros vs. cons and pricing, I think I'd personally be
comfortable in giving it a try for home use (when I have an actual need
or a really burning desire for it) after some further detailed research
about the nitty-gritty implementation and rollout details. If/when I
ever do this, I'd be more than happy to do an objective write-up for
interested parties for both the good and bad parts.

A very nice thing is, if you're just evaluating the solution, you don't
have to buy the server side component -- Yubicorp provides hosted
storage of key data for evaluation purposes. This brings down the cost
of evaluation to perhaps the cost of just a single key or a bit more. So
that's why I'd likely give it a closer look for at least evaluation. I'm
out, what, $25 and an hour of my personal time, if this doesn't work out?

As for 2FA auth in general, the exact type of fob/key depends on one's
needs. If you wish to encode other data (say, biometrics -- iris,
fingerprints, S/MIME cert, photo, basic employment details such as an
employee ID number, PGP/GPG public key, other unique facility or
organization-specific information), then you'd need either a USB
flash-based key or smart card of some kind + a programming device.

Integration can be a bit more involved such as deploying a PKI
infrastructure. Also, there's the overhead of maintaining that
information over time.

If it's just for simpler auth needs, the OTP-type tokens often works out
well, and have a lower integration overhead.

I haven't really found any F/OSS setup for traditional hardware-based
2FA that I was fully comfortable with (looking at the big picture -
hardware, software, integration, long-term maintenance and support).

That's why I'm willing to pony up a little money to reach my goals. I
say this as someone who is one of the biggest proponents of F/OSS tools
for the last 25 years.

But ultimately, anything is possible, given sufficient time, technical
datasheets, coding, hacking, assembly, and reverse engineering. ;-)

For cheap, quick, easy setups, S/Key or OPIE may be the way to go. I've
used it and works OK. 2FA's too much overhead and cost if your needs (or
wants) really don't require 2FA.

-Dan
_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to