Category: mobile

IAM for the smaller enterprise

My clients find identity solutions to be complex and costly to implement.  For mature and/or large enterprises, these issues are simply a cost of doing business — and compliance or online strategic drivers are usually sufficient to fund and launch an IAM initiative.

For the smaller enterprise there appear to be two paths followed: do nothing or do it poorly.  When done poorly, shoddy IAM implementations  can result in poor credential management, lousy availability and inappropriate access controls.

So how does a smaller company or organization deal with identity properly? How can users be efficiently identified online without building expensive, custom solutions? What service levels and supports are possible for a login service when staff go home at 5pm? How can niche needs like strong authentication be met without excessive server license costs and complex implementations?

Enter the cloud.  Cloud-based IAM service providers are maturing and there are a number of solutions that offer the smaller organization solutions.  For example:

  • Symplified offers a full IAM service that promises plug-and-play integration with surprising depth, including support for mobile devices and apps.
  • PhoneFactor has a slick and secure solution for two-factor authentication that can be licensed on a per-use basis.
  • TransUnion have a robust identity proofing service for the critical process of confirming the identity of an online visitor.

Using one or more of these solutions allows for rapid deployment of IAM for smaller organizations.  The cost savings are considerable and services levels are beyond what most companies could hope to provide on their own.  There still remains integration work — applications need to be ‘plumbed’ to inter-operate with the cloud solutions — but all the heavy-lifting of designing and configuring a solution is eliminated.

The maturation of cloud IAM solutions means an increased number of companies can implement secure and compliant solutions without the long lead-times and high cost of traditional product-based offerings.  In this age of rampant data breaches and increased focus on compliance, this is a welcomed development.

Mike

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?

Mike

Strong Authentication, Multiple Options

I’ve been thinking about strong authentication (SA) lately as it relates to some client work I’m doing.  The technology has matured over the past few years, and the acceptance by both users and clients is growing.  A few years ago I would deliver presentations on multi-factor authentication and I would pass around an RSA SecurID fob.  Fully half the audience had never seen one and had no idea what it was for.  Today, you’d be hard pressed to find an enterprise or government user who was unfamiliar with SA devices.

So what are the current options for SA?  My SA world right now is mostly concerned with public access to confidential information held by government, education and health organizations, so I’ll limit the scope to applications in these spaces.  

This makes it easy to eliminate a few things: for real and perceived privacy reasons, biometrics are difficult for public users to accept, and a lack of readers on individual user desktops is a problem; smart cards are an excellent technology platform for SA, but again readers are not yet common for a public-scale roll-out to be successful; certain one-time password (OTP) token solutions — including the venerable RSA SecurID — are cost prohibitive for deployment to large numbers of public users; and software tokens, those virtual token generators running on the desktop PC, are prone to virus attach and too easy to share between users from the same household.  (More to this last point, software-based tokens can be deployed to individual users on a shared desktop, but then access to the token is inevitably protected by a password… Not really an SA solution by most definitions.)

Fortunately, that still leaves a fairly large number of options:

USB tokens — There are a number of tokens that are available on a USB (Aladdin, RSA, etc.) format.  Most are deployed with a certificate and work within PKI environments.  The devices are becoming viable for large implementations because USB devices are easily supported on most computers, and the general public have become much more comfortable in plugging devices into USB ports.

Value-priced OTP fobs — Entrust, Activeidentity and others have driven the cost of fob-based SA systems to less than a third of RSA SecurID.  While these products might not RSA’s robust encryption, many large deployments are at least considering traditional tokens again due to these lower cost options.

Grid cards — Also known as ‘paper authenticators’ or ‘Bingo cards’, these wallet-friendly cards contain rows of numbers organized in a grid.  The authentication system prompts the user for values on the cards by column and row.  Because the user possesses a unique card, this provides SA. Drawback: grid cards are easy to duplicate…  A variation, one-time ‘scratch’ cards, overcome this limitation.  OTPs are hidden under a scratchable surface (think scratch lottery tickets) and a new one is used each time for access.

Mobile SMS — One of the more difficult problems (and cost concerns) with large-scale SA is the issuing and managing of SA devices.  Mobile SMS addresses this problem by using an authenticator that the user already has: their mobile phone.  An SMS message containing an OTP is sent to the registered user, and this OTP is used as the second factor in the authentication.  More robust implementations replace SMS with a phone-generated token.  Mobile SMS solutions benefit from the widespread use of cell phones (especially among younger users) and the high percentage of time people have them in their physical possession.

Voice delivered token — A variation on the mobile phone authenticator is to deliver the OTP via an automated voice call.  This can provide some additional security when combined with a PIN and a voice-delivered OTP might be easier for certain public users to use, particularly those with vision problems or certain cognitive challenges (e.g. dyslexia).

This narrowing of the options makes analysis of SA solutions for large public user projects a bit easier:

  • Is low cost a primary driver?  Grid cards and Mobile SMS are likely your best options.
  • Worried about device or card management? Mobile phone solutions gently push this task onto your users.
  • Do you want the flexibility to store certificates and data?  USB tokens are proven solutions to meet this need.
  • Are you (or your users) most comfortable with a ‘traditional’ fob solution?  Look to cost-savvy providers of OTP tokens.

Finally, blending these technologies into a solution is recommended.  For example, not all users possess cell phones, so you’ll want an alternate technology (fob or grid card perhaps) as an option.  In the public user space, you need to be careful about forcing a specific technology on to your user base — a degree of user choice is always recommended.

Ultimately it is a matter of picking the best solution to meet your needs — and no matter what your criteria may be, today’s SA vendors truly have viable options to offer.

Mike