Authenticating those youngsters

IAM consulting for mobile authentication solution
Why can’t a device replace a password?

I had a really interesting conversation with a client last Friday.  I’ve helped them to build a public-facing identity management system for access to a range of web applications.  It has been running for over two years and has (literally) hundreds of thousands of users.

The chat went something like this…

CIO: As you know, our users are a bit of a younger demographic, and we’ve been noticing lately that they are having trouble remembering their usernames and passwords.

Me: Well, we’d expect them to use the forgot user ID or forgot password links on our login page…

CIO: But they don’t. Or if they do use those links it is confusing to them. We are seeing a spike in help desk calls.

Me (mystified a bit): Ummm… why is that? We use a pretty standard web page with links for these functions.

CIO: Yes we do. However, an increasingly large segment of our user base has grown up with smartphones, not browsers. They are used to apps and auto-remembered credentials.

Me (feeling elderly): Oh.

CIO: So what we need is a way to login to both web apps and device apps using just the mobile phone.

Okay, so it took a few minutes for this to sink it, but I get this. Younger users use mobile phones and apps predominantly, and the web browser experience is not the same for them as it is for us oldsters.

My own teen-age kids are proof of this — texting is definitely preferred over email, and I think I saw my 15-year old daughter tear-up last year when I upgraded her iPhone to a full data plan…

Teens, it seems, are most comfortable with a device.  And that device presents information and services differently than a web page does.  So differently in fact that it poses problems for authentication. This is really interesting…

There are two use cases to explore here.

  • The first is the identity-aware app.  The app needs to authenticate the user in a way that is consistent with best-practices for protecting sensitive information.  It can’t just provide access without authentication because that would be against policy and create risks of breach that aren’t acceptable.  But it does need to be seamless and easy — because that is the way of the app, right?
  • The second case is web login without username and password… Interestingly, a user ID / password combination is only single factor (something-you-know).  The replacement of this standard approach with something-you-have, i.e. a mobile device, shouldn’t be that hard.  For example, a user who has pre-registered their phone with us could get a one-time code sent via SMS to the phone.  They could then enter the code in order to authenticate.  No more forgotten passwords, no need to remember what username I picked.

Can these use cases be met within the policies and best practices established by enterprises? Or do we need to reconsider our approaches in light of a changing demographic?


Combining security responsibilities

Many clients and more than one IT security ‘expert’ have told me that there are few differences between the processes and organizational constructs of IT security and physical security.  Both are concerned with protecting the company from bad guys, whether their assaults be on the ground or on the wire. 

Is this true?  It would seem that the jury is still out – while I know one company where this has been implemented, many others are still managing IT and physical security as separate groups.

Both CSO Online and Computer World have written about this topic, and the issues seem to be related to cultural and pay.  IT culture is experimental and dynamic, whereas traditional security takes a more conservative approach.  And because salaries for employees in IT shops can be quite a bit higher than those paid for physical security staff, there is a risk of staff conflict if these groups are combined.

But there are many opportunities to share process and management efforts.  Identity proofing process are (or should be) virtually the same.  Authentication/access devices can be combined and managed together.  Monitoring of IT and physical security feeds can be made more efficient.  And a single point of contact (CSO) – with easy information sharing – can reduce impacts of breaches and false alarms.  All these add up to big cost savings, improved efficiency and improved security.

Do the benefits out-weigh the difficulties of merging and then managing all security staff as a single unit?


Convergence is the prize…

I mentioned in the last post that we recently reviewed hardware and software that could work well for solutions that converged authentication, building access and (potentially) entitlements.  Two stood out from the rest: HID Crescendo cards and Aladdin’s USB eTokens.

Building access cards are ubiquitous in companies that have secured buildings and offices.  HID Corp. are the defacto building access solution (at least around here) and many large companies have a significant investment in HID products.  The Crescendo card has two proximity anttenae and a smart chip for storing digital certificates or other data.  In our project, we were able to (quite easily) prove that the card would gain access to our building, and provide strong authentication during network login.  Other potential uses include:

  • Preboot authentication
  • Storage of entitlements, e-cash or other pre-payment data
  • Employee picture ID card
  • Disk encryption

Aladdin’s USB eToken has similar capabilities, albeit in a different form factor.  We proved that it can provide strong authentication to Windows using Aladdin’s replacement login utility.  It can support all the same features as the HID solution — yes, even a proximity component for building access is possible — except, obviously, the picture ID.

The point of this post isn’t to promote these products — there are others that can produce the same results — but rather to illustrate how technology can support convergence use cases.  Users don’t want a card for building access, another for picture ID, a fob for network access and a USB for pre-boot authentication. 

Convergence of these capabilities into a single form-factor should be the goal for the simple reason that it increases acceptance of the IT security solution being implemented.  Greater acceptance = higher usage and better security.


Strong Authentication – and convergence

Recently, I had a mid-sized municipal government ask us to help them discover different technologies for strong authentication.  The great part about this project was that they were very keen to find out how the actual products worked – as a result we were immersed in gadgets and slick software for over two months.

The purpose of the project wasn’t to pick a solution or prepare requirements for a future tender.  Rather it was to enable the client to experiment with different solutions – and to validate the claims of assorted strong authentication vendors.  Another interesting aspect of this work was the inclusion of physical building access and transit entitlements, with the goal of uncovering what convergence options there were for this family of technology.

We had a solid lineup of vendors on our test bed: Entrust, Secure Computing, HID, Aladdin and RF Ideas.  Operating systems included Microsoft Server 2003 and Red Hat Linux.  We looked at USB tokens, fobs, grid cards, SMS messaging, proximity cards, smart cards and combination cards.  Much fun was had…

Over the next few weeks I’ll share some of the learnings of this project, but the first finding was this: Authentication, physical access and entitlement technologies can be converged into single solutions.