Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Hitachi ID Systems Blogs

Archive for September, 2009

Which authentication factor makes sense?

Wednesday, September 23rd, 2009

We’ve been discussing strong authentication options with one of our
customers lately, and I thought I’d post some thoughts about the
strengths, weaknesses and suitability of a couple of technology options.

The business driver our customer is facing is a corporate mandate for
strong authentication — and in particular “stronger than passwords.”
I won’t delve deeper into their needs than that — presumably they know
what they want and why they want it.

In the past, this particular organization, which happens to be a company
with world-wide operations, has deployed smart cards to authenticate
users into their Windows PCs and into the corporate VPN.

Today, there is some question about whether to continue with the smart
cards. This is really for two reasons:

* The cost of ownership of smart cards has been and continues to be
relatively high.

This is presumably due to a combination of factors: the need
to acquire physical cards and readers for each PC, the need to
initialize those cards for new hires and collect/deactivate cards and
the PKI certificates they carry at termination time and (relative
to passwords) complex and costly processes to support users with
lost or stolen cards or who forgot their PIN.

* While the smart cards work quite well for users signing into corporate
PCs (desktop or laptop running Windows and a member of the corporate
AD domain), they don’t work at all when a user wishes to access
an application using a smart phone, their home PC or (conceivably,
anyways) an Internet kiosk.

So what are the alternatives, if the basic requirement is “strong”
authentication and the practical meaning of that is “two factors?”

Really the only other technology out there is one time password tokens,
such as RSA SecurID or Vasco Digipass. Tokens have strengths and
weaknesses of their own:

Strengths of tokens:

* While you do have to provision tokens to users, there is no associated
“reader” hardware.

* Eliminating the reader reduces hardware and integration costs.

* Eliminating the reader also means that tokens work well from smart
phones, home PCs, kiosks, etc.

But everything comes at a price. The weakness of tokens is that they
are not really suitable for mobile users signing into their laptop when
it’s not connected to the network. This is because a server is needed
to validate the token’s current pass-code, and if a user is off-line,
the user’s PC cannot contact the server to do that.

There are other technologies, of course. For example, there are “1 1/2″
factor systems where a user clicks around an image. There are also
systems where a server sends an SMS message to a user trying to sign
into an application, where the contents of that message are a one-time,
random PIN the user must type to sign on.

These kinds of solutions are cool, but they don’t generally work well on
smart phones — for example, would you have to hang up your smart phone
web application login to read the SMS PIN, and then relaunch the micro
web browser to sign on again? That sounds awful!

So really we have two technologies, each of which is suitable for a
different scenario:

* Smart cards: more expensive to deploy and manage, optimal for
signing into the corporate PC.

* Tokens: somewhat less expensive to deploy and manage, optimal
for VPN access, home PCs and apps accessed from a smart phone.

It seems like the best solution is actually to deploy *both*. The
trouble with that, of course, is cost. There are certainly combination
devices out there that function as both a smart card and OTP device:

http://rsa.com/experience/sid800/RSA_SID800_Final.html

http://www.globalsmart.com/VASCO_Launches_New_Version

http://www.thefreelibrary.com/Aladdin+Introduces+Software-Based+Smartcard+and+OTP+Authentication…-a0198208471

One way to save money is to look at USB-attached devices, that
electronically act like smart cards but don’t require a reader.

Another way to manage costs is to automate management processes:

* Onboarding new users — and automatically allocating a device,
streamlining how it’s initialized, etc.

* Supporting users who forgot their smart card and/or token PIN –
using self-service.

* Supporting users whose device was lost or stolen, through self service
access to temporary emergency access passwords.
using self-service.

Ultimately, organizations have to ask themselves if all this cost and
complexity is really warranted by the improved security. Yes, these
authentication technologies are more robust than passwords. But are
passwords really so bad, if they are complex and changed regularly?
The cost/benefit calculation may not be as compelling as one might
first think.

XML APIs? Yes. XML in the DB? No!

Wednesday, September 23rd, 2009

Dave Kearns writes about the XML infrastructure in Microsoft’s new IAM product:

http://www.networkworld.com/newsletters/dir/2009/092109id2.html?source=NWWNLE_nlt_security_identity_2009-09-23

I don’t think XML is *necessarily* a good thing!

Yes, its’ a great way to package APIs for communication between two systems. That’s what XML was always designed for and it does a great job.

But some vendors – in the IAM space and elsewhere, and I think this includes Microsoft’s Forefront Identity product, store XML “blobs” in the database to represent complex data structures, such as users along with their identity attributes, roles, accounts and group memberships.

Storing XML objects in the database is actually *terrible*. It can kill performance — try running a search through a table where a given attribute of an XML blob in some column has a given value!

It also pretty much eliminates the possibility of using third-party tools to run reports against the data. You want to use Crystal Reports, for example, to see what users are in some group and have some role? Too bad for you! That data is encoded in XML blobs that the reporting program can’t parse.

So yeah, having a web services, XML-based API is great. But storing XML in the database is nothing more than the product of lazy programmers who can’t be bothered to update the database schema to reflect the evolving needs of their app.