Rational Survivability

I’ve been following with some hand-wringing the on-going debates regarding the value of two-factor and strong authentication systems in addition to, or supplementing, traditional passwords.

I am very intent on seeing where the use cases that best fit strong authentication ultimately surface in the long term.  We’ve seen where they are used today, but Icub wonder if we, in the U.S., will ever be able to satisfy the privacy concerns raised by something like a smart-card-based national ID system to recognize the benefits of this technology. 

Today, we see multi-factor authentication utilized for:  Remote-access VPN, disk encryption, federated/authenticated/encrypted identity management and access control, the convergence of physical and logical/information security…

[Editor’s Note: George Ou from ZDNet just posted a really intersting article on his blog relating how banks are "…cheating their way to [FFIEC] web security guidelines" by just using multiple instances of "something the user knows" and passing it off as "multifactor authentication."  His argument regarding multi-factor (supplemental) vs. strong authentication is also very interesting.]

I’ve owned/implemented/sold/evaluated/purchased every kind of two-factor / extended-factor / strong authentication system you can think of:

• Tokens
• SMS Messaging back to phones
• Turing/image fuzzing
• Smart Cards
• RFID
• Proximity
• Biometrics
• Passmark-like systems

…and there’s very little consistency in how they are deployed, managed and maintained.  Those pesky little users always seemed to screw something up…and it usually involved losing something, washing something, flushing something or forgetting something.

The technology’s great, but like Chandler Howell says there are a lot of issues that need reconsideration when it comes to their implementation that go well beyond what we think of today as simply the tenents of "strong" authentication and the models of trust we surround them with:

So here are some Real World goals I suggest we should be looking at.

1. Improved authentication should focus on (cryptographically) strong
   Mutual Authentication, not just improved assertion of user Identity.
   This may mean shifts in protocols, it may mean new technology. Those
   are implementation details at this level.
2. We need to break the relationship between location & security
   assumption, including authentication. Do we need to find a replacement
   for “somewhere you are?” And if so, is it another authentication factor?
3. How does improved authentication get protection closer to the data?
   We’re still debating types of deadbolts for our screen door rather than
   answering this question.

All really good points, and ones that I think we’re just at the tip of discussing. 

Taking these first steps is an ugly and painful experience usually, and I’d say that the first footprints planted along this continuum do belong to the token authentication models of today.  They don’t work for every application and there’s a lack of cross-pollinization when you use one vendor’s token solution and wish to authenticate across boundaries (this is what OATH tries to solve.)

For some reaon, people tend to evaluate solutions and technology in a very discrete and binary modality: either it’s the "end-all, be-all, silver bullet" or it’s a complete failure.  It’s quite an odd assertion really, but I suppose folks always try to corral security into absolutes instead of relativity.

That explains a lot.

At any rate, there’s no reason to re-hash the fact that passwords suck and that two-factor authentication can provide challenges, because I’m not going to add any value there.  We all understand the problem.  It’s incomplete and it’s not the only answer. 

Defense in depth (or should it be wide and narrow?) is important and any DID strategy of today includes the use of some form of strong authentication — from the bowels of the Enterprise to the eCommerce applications used in finance — driven by perceived market need, "better security," regulations, or enhanced privacy.

However, I did read something on Michael Farnum’s blog here that disturbed me a little.  In his blog, Michael discusses the pros/cons of passwords and two-factor authentication and goes on to introduce another element in the Identity Management, Authentication and Access Control space: Single-Sign-On.

Michael states:

But here’s s [a] caveat, no matter which way you go: you really need a
single-signon solution backing up a multi-factor authentication
implementation.  This scenario seems to make a lot of sense for a few
reasons:

• It eases the administrative burdens for the IT department because,
  if implemented correctly, your password reset burden should go down to
  almost nil
• It eases (possibly almost eliminates) password complaints and written down passwords
• It has the bonus of actually easing the login process to the network and the applications

I know it is not the end-all-be-all, but multi-factor authentication
is definitely a strong layer in your defenses.  Think about it.

Okay, so I’ve thought about it and playing Devil’s Advocate, I have concluded that my answer is: "Why?"

How does Single-Sign-On contribute to defense-in-depth (besides adding another hyphenated industry slang) short of lending itself to convenience for the user and the help desk.  Security is usually 1/convenience, so by that algorithm it doesn’t.

Now instead of writing down 10 passwords, the users only need one sticky — they’ll write that one down too!

Does SSO make you more secure?  I’d argue that in fact it does not — not now that the user has a singular login to every resource on the network via one password. 

Yes, we can shore that up with a strong-authentication solution, and that’s a good idea, but I maintain that SA and SSO are mutually exclusive and not a must.  The complexity of these systems can be mind boggling, especially when you consider the types of priviledges these mechanisms often require in order to reconcile this ubiquitous access.  It becomes another attack surface.

There’s a LOT of "kludging" that often goes on with these SSO systems in order to support web and legacy applications and in many cases, there’s no direct link between the SSO system, the authentication mechanism/database/directory and ultimately the control(s) protecting as close to the data as you can.

This cumbersome process still relies on the underlying OS functionality and some additional add-ons to mate the authentication piece with the access control piece with the encryption piece with the DRM piece…

Yet I digress.

I’d like to see the RISKS of SSO presented along with the benefits if we’re going to consider the realities of the scenario in terms of this discussion.

That being said, just because it’s not the "end-all-be-all" (what the hell is with all these hyphens!?) doesn’t mean it’s not helpful… 😉

Chris