RT @cmswire: CrossIdeas Acqusition Underlines IBM's Security Drive by @druadh20 http://t.co/q6nxH7uwIs #eim #mampa
@cmswire @druadh20 thanks for the coverage! #ibmsecurity
@AFairch thank you for sharing Alea. #ibmsecurity
@VentureBeat @RuthReader thanks for the coverage #ibmsecurity
RT @VentureBeat: IBM buys CrossIdeas in struggle to meet cloud security demands http://t.co/sN8Ek1hUIP by @ruthreader http://t.co/WtdQQsMUCp
201309Passwords-are-Dead-We-Need-a-Better-System-Now.jpg

Are Passwords Dead? We Need a Better System Now


Passwords are failing us

“Our passwords are failing us.” said Michael Barrett, PayPal’s Chief Security Officer.

He’s not alone. According to the Verizon 2013 Data Breach Investigation Report, roughly 76% of all data breaches were enabled by weak credentialing and user authentication. So, we might safely say that most, if not all of our traditional security measures do little to close credentialing vulnerabilities. If that’s safe to assume, then we need to discuss replacing them with something that does work.

In fact, according to a May 2013 whitepaper, US Mobile Payments Landscape-Two Years Later, which was produced jointly by the Boston and Atlanta Federal Reserve Banks, mobile payment services are advancing faster than expected, but without much regard to standards and security. The Paper notes “unresolved security and privacy issues.”  It further suggested that “as the [mobile payments] ecosystem matures, it will challenge new entrants in their ability to achieve scale and sustainability.”  It further concluded “the need for interoperability, industry guidance and standards to ensure a secure and cost-efficient ecosystem.”

The story is bigger than you think

Yet, the story is bigger than that. You’ll hear us repeat phrases like Secure Credentialing or Privilege Entitlement and Access Control.”   That’s because it’s actually the correct way to think about things like mobile payments. After all, what are “mobile payments?”  Aren’t they your ability to pay, crammed into your phone?  What are we cramming into that phone?  A credit card or debit card?  What’s that? A credit card is nothing but a piece of plastic, with a number written on it, which represents your PRIVILEGE to use a pre-approved bank line-of-credit.

Now just consider how many credentialed privileges we enjoy on a daily basis.

  • Driving a car (driver’s license)
  • Boarding a train or plane (ticket/boarding pass)
  • Entering a building (security badge)
  • International travel and immigration (Passport/Visa)
  • Accessing Government services/Entitlements (Social Security Card/Medicare Card)
  • Network access and logon (Password/PIN)
  • Using a cell phone (SIM card)
  • Employment (Corporate ID)
  • Education (school ID)
  • Healthcare (health card)
  • Web-services (SSL/PKI certificate)

We enjoy these privileges daily without even thinking about them and they are all represented by a credential of some sort.  Of course, these privileges are extremely valuable, which is why people try to steal them or damage them. Thus, the credentialing system is nothing but an access control system designed to protect access to those valuable privileges. With seemingly countless data-points and frequent news reports of data breaches, it’s hard to argue, with a straight face anyway, that what we have been using to protect our valuable online assets, services and privileges actually works. Biometrics seem inevitable.

The case for biometrics

Of course, the privileges are represented by a numeric value, aren’t they? A card number? A user ID number? (We are all “just a number” to them, aren’t we?). Those ID numbers are being digitized, but still represent the same entitled privileges. They can and are being stored in computer files within our PCs, laptops, tablets and smart mobile devices. And so, as we step back to account for this movement, we can see the evolutionary migration of all our credentials into our smart devices, which are increasingly mobile.

In fact, we see major technology providers attempting to stand up “digital wallets,” exactly for the purpose of administrating those digitized privilege credentials. For sure, one day soon, all our credentials will reside in our smart mobile devices. Those devices will communicate and guard those privilege credentials. Consequently, each mobile device and credential must interoperate with the multitude of disparate services and providers accessed by the credentials housed in the device.

Why the password is dead

Central to any Privilege Entitlement Access Control negotiation is the concept of risk.  The level of potential risk to the asset or service determines the required level of security, including strong user authentication, before access is granted. Further, the binary decision to deploy strong authentication, including biometrics, is also risk based and, specifically economic risk-based, which can also be viewed as economic feasibility. Stakeholders won’t deploy it if they lose money at it.

The reason industry stakeholders and technology leaders have declared traditional Credentialing & Access Control systems dead, like password/PIN, is because the expense of the frauds and breaches has become sufficiently large enough to offset the cost of replacing those systems. The risk of relying on traditional access control mechanisms is now too high.

Today, the question of “should we upgrade our Privilege Entitlement & Access Control Systems?” has been replaced with:

  • How should we upgrade these systems?
  • How do we upgrade the system as efficiently as possible without compromising trust or incurring risk?
  • How do we do that in a distributed mobile network environment?

To answer these questions, we must consider the authentication system design, in terms of economic feasibility, liability, trust and convenience.  Unfortunately, these concepts are perceived and valued very differently by service providers than by consumer privilege holders.

Importantly, the location of the authentication transaction affects the risks, liability, convenience and economic feasibility for the service provider and consumer differently. Consider that there are effectively only two locations the user-authentication transaction can occur; on the device, and/or in the cloud. Let’s consider each location in terms of economic feasibility, risk, liability and trust.

Authentication on the device

Authentication on the device implies just that, processing the authentication of the user on the phone.  Many phone manufacturers contemplate including fingerprint sensors on the device to authenticate the phone user, presumably the entitled privilege holder associated with the credentials stored on the phone or in some data repository elsewhere.

On-device authentication suggests that the fingerprint comparison occurs, or is transacted, literally on the phone, with a binary result then transmitted securely to the service provider for acceptance or rejection. In this case, the service provider accepts higher risk and liability, as that service provider must agree to trust any and all authentication data transmitted from that phone. This means the service provider has limited control of the risk and may be unlikely to accept this authentication in higher-value transactions. Moreover, this model may be less economically feasible as that service provider must also support the potential multitude of disparate and proprietary authentication data sources that could be generated by any number of handset manufacturers, cellular operators, fingerprint sensors or matching algorithm template providers. This could be costly to administrate and support.

However, refusing to support various disparate authentication systems could create inconvenience for the potential customer, including and maybe especially the enterprise customer, requiring the customer to use a select phone manufacturer or forgo the benefit of the service. Moreover, the customer owning multiple devices would be required to enroll on each device and potentially for each service.  Further still, the enterprise customer may experience significant friction and cost related to upgrades and end-of-life replacement plans and is, thus, unlikely to invest in this model.  Therefore, in my opinion, this model may be utilized early in the adoption cycle for strong mobile credentialing, but is less likely to enjoy long-term or deep penetration. The system will evolve to something different.

Authentication in the cloud

Authenticating in the service providers cloud implies capturing the biometric data on the phone and securely retrieving or transmitting it to the service provider’s cloud, where the authentication transaction takes place.  In this case, the service provider could reduce risk by comparing user-authentication data, captured during applicant enrollment, to data of existing customers to negate dual enrollments and fraud.  This is not possible when enrolling and authenticating on the phone. Further, the service provider would enjoy reduced risk by maintaining control of the authentication process.  It seems natural that the service provider can trust its own, in house, systems more than those owned and operated outside the service provider’s control.

Deploying a hardware and operating system agnostic authentication engine in the service providers cloud would provide complete interoperability with handset input devices, significantly reducing the service provider’s capital investment in multiple disparate authentication engines.  This would further allow the individual and enterprise customer the choice of handset providers, without disrupting service availability, reducing friction and cost, while increasing convenience of upgrade and end-of-life replacement.  Both consumer and enterprise customers are likely to prefer and invest in this model, as a result.

In my opinion, this model reduces risk and capital outlay to the service provider, while increasing convenience to the consumer. This model is viable in enterprise environments, while the on-device model is not. Thus, I believe strong authentication in the mobile credentialing evolution will emerge on-device, primarily in consumer applications, but will migrate to the cloud over time, which will facilitate enterprise adoption.

Identity anywhere: Secure Mobile Credentialing & Identification

There is, however, a third design option involving a third-party authentication service in the cloud. In this case, the on-device sensor captures the print, converts it to a template and securely sends it to the third-party cloud, which presumably would utilize the aforementioned single hardware/operating system agnostic and interoperable authentication engine. The service provider must agree to trust binary authentication confirmation data from the third-party provider, but this would eliminate the need to trust more than one outside source. Otherwise, this design would operate similarly to that of the service provider cloud-based system.

Assuming the third-party authentication service provider incorporates hardware and operating system agnostic (interoperable) systems, the consumer and enterprise customer would enjoy open choices between handset providers, who also would enjoy open choices between sensor providers. This would reduce risk and cost to the service provider, the handset manufacturer and, both, the consumer and enterprise customer. The third-party authentication system would allow the consumer and enterprise customer to enroll only once, but associate that single user identity with multiple services and across multiple devices, regardless of make or design. In effect, the third-party, cloud-based authentication service would allow for “Identity Anywhere” or “Identity Everywhere.”

Mobile payments are part of a larger Secure Credentialing & Identification evolution. Our Privilege Entitlement & Access Control systems are migrating into the emerging smart mobile computing ecosystem and must satisfy both risk and economic requirements, without excessive friction. The migration of these strong authentication systems, including biometrics, will emerge on devices in relatively cumbersome consumer-facing applications. They will continue to migrate to the cloud and ultimately will largely reside and function in the cloud. Risk determinations, including economic feasibility, will determine whether the authentication occurs in the service providers cloud (highest risk assurance), or in the third-party cloud (middle risk assurance), or on the device (light risk assurance). End-user convenience and cost, will likely drive the majority of Mobile Credentialing authentication to the cloud, especially at the enterprise level.

I encourage you to consider the evolutionary trajectory of such capabilities and invest accordingly.

Topics: , , , , , ,

Related News

4 comments
CoryTV
CoryTV

jamlink1 Great point. Really.

jamlink1
jamlink1

CoryTV What if you don't have fingers?

Mojoreizer
Mojoreizer

CoryTV I wonder how much of the precious battery life the fingerprint lock will use over d course of d 3 hours before required charging