Authentication debate fuelled by Apple Touch ID is in itself a game changer

There's a good debate on ZDNet between John Fontana and David Braue around the issue of whether Apple's Touch ID is a game changer. I've spoken to, discussed things with and read stuff written by both these guys, so I can vouch for the fact they know what they are on about, which is why I'm sort of fence sitting in the context of their actual debate. But if someone shook the fence I'm currently sitting on vigorously and I assume the question was framed around Touch ID in its current form (or rather, how it will be when the iPhone 5s is released in a few days), I'd probably fall onto the side that John's on.

John makes 2 really great points that I wholeheartedly agree with:

"Currently, Touch ID has no way for the enterprise to tap the technology into their identity and access management systems."

and

"...without an SDK, developers that made the App Store explode won't be able to lift a finger to raise Apple's security profile above a whimper."

He's right. But I believe Apple will eventually allow developers to hook into Touch ID, albeit indirectly. Apple does not build things into their devices without a long-term strategy for them.

Those of us in the IT security field are paid to be paranoid and sceptical, so I can understand how security professionals are not jumping on the Apple fanboy bandwagon. Interestingly enough, many are closet Apple fanboys when not doing their day jobs. One thing we all struggle with however, is getting people to actually care about security, let alone openly debate it.

While I don't believe that Touch ID in its current form is a game changer, the fact that Touch ID's lit the fire under the authentication debate is. That is something only companies like Apple can do.

While it may seem self-serving to quote myself, that's exactly what I'm going to do. I said in my previous blog post:

"...it will take at least one well-known brand with a significant amount of consumer influence to fork-lift-point us down the non-password oriented identification path."

Apple's done that. If you read some of David's arguments in the debate, he's actually projecting potential future applications of Touch ID, not features it will have upon initial release:

"MDM tools are all about adding a layer of control to distant mobile devices, and fingerprints are a readily available way for distant users to prove their identity."

and

"Better API access would allow developers to use fingerprints anywhere they now require user ID-and-password combinations."

Sitting firmly perched back on my fence, I agree with John that Touch ID in its current form is not a game changer. But I agree with David that Touch ID's potential, with the Apple juggernaut behind it, is.

At the very least, the fact that authentication has become a hotly debatable topic in the mainstream is the actual, indisputable game changer that Apple's managed to fuel with the introduction of Touch ID. As an added bonus, if your day job is to sell security internally to C-level decision makers, here's a potential way in to start those security conversations. Remember to leave the propeller hat behind in your desk drawer.

Usable identification - the key to a world without passwords

Consumer devices offer the best vehicle in bringing non-password based authentication mechanisms to the mainstream much the same way social networks have brought identity federation to the masses. It is the best shot we have of eventually killing passwords off for good. If that day comes, passwords will more than likely be replaced by a combination of biometric and token-based mechanisms.

The inevitable rise of wearable computing in addition to the ubiquity of smart phones will result in an abundance of options (compared to a world before smart phones) in available tokens to use as part of the identification dance known as authentication.

Signing on to a site using your social network is not commonly referred to as identity federation; that's what security people call it. But it works because it's usable, although this is at the expense of some security. Social identities help consumers clear the security hurdle to the point where the word "security" doesn't rate a mention during the authentication and/or registration process. Social networks however, still use passwords.

Passwords on their own are insecure. In the absence of other ways to identify ourselves (i.e. multi-factor authentication), a lot of damage can be done to our digital lives that are difficult to recover from. Also, let's not forget about the number of hacks suffered by multiple sites that included leaked passwords. But they remain because the username and password combination is a design pattern we have been trained to understand and accept. Because we have been conditioned this way, passwords are inherently usable. Therein lies the challenge in moving past them.

Good authentication practices have always included multiple factors. In other words, passwords on their own just won't do. In addition to usability, cost is almost always a prohibiting factor. It costs an organisation a lot of money to procure the hardware required to support authentication mechanisms beyond passwords. Wouldn't it be nice if consumers had tokens they could use that were as secure as these expensive ones organisations currently have to buy?

Some organisations have weighed the risks against costs and decided that SMS tokens are good enough to be considered as an acceptable second factor beyond passwords. If you've looked into this, you know SMS messages are not actually that secure. But for a lot of scenarios, they are "good enough" when combined with the primary password. If organisations want to move beyond this however, it gets very expensive.

It took well-known brands with a significant amount of consumer influence (e.g. Facebook, Twitter, LinkedIn) to bring identity federation to the masses. Similarly, it will take at least one well-known brand with a significant amount of consumer influence to fork-lift-point us down the non-password oriented identification path.

In the case of authentication however, there is the cost consideration that was not present in the consumer identity federation equation. How can we put stronger authentication factors in the hands of consumers in a cost effective manner? Ideally, we would make consumers buy these tokens, but who would want to do that just for a bit of extra security and a more disjointed user experience? Enter large, well-known consumer brand with the requisite influence.

Apple, the king of making technology usable is that organisation. Their announcement yesterday of the Touch ID fingerprint sensor on the iPhone 5s is the latest (and loudest) in a recent spate of devices that have the potential in helping achieve the right balance of usability, cost and security at scale. Rich Mogull's article on TidBITS is the best one I've read if you want to understand some of the security aspects.

Beyond Cupertino, there are a few recent developments that will hopefully be caught up in the Apple authentication snowball that is rolling down security mountain:

• Nymi is a device which wraps around our wrist and uses our unique cardiac rhythm to authenticate and identify us to things around us. There are unknowns around how or if this will actually work, including some more knowledgable about cardiac rhythms than I, who remain sceptical. Dave Kearns however, is a little more enthusiastic, as are most other people on Twitter. I for one, hope it actually works because the potential scenarios are interesting, exciting even.
• Let's not forget about the impending barrage of smart watch releases over the next year, starting with Samsung's Galaxy Gear. Apple of course, has also been working on the rumoured iWatch. Even car manufacturers like Nissan are clamouring to wrap themselves around our wrists. While smart watches aren't inherently security devices, they are effectively another token that could be used in the authentication process. For example, the fact that a smart watch is mine and is paired with my smart phone (or car in the case of Nissan) at the point of identification (authentication) gives the system identifying me a level of assurance that I am who I claim to be.

As with any new technology, there are potential security implications that need to be analysed and I'm sure this will be done by many when the devices are made available to the general public. But Apple Touch ID, Nymi, smart watch manufacturers and other wearable devices we have yet to hear about have the potential to make security invisible.

Security is the enemy of usability. Studies have shown that when presented with a secure option or an easy option to perform a task, people almost always choose the easy option. The trick is to make the easy option also the secure option. The devices mentioned aim to make our lives better. The fact that they have the potential to make our lives easier while improving security is exciting.

Here's to a future where we don't need passwords, but can stay secure while remaining blissfully ignorant of that fact.

Some answers on Identity enablement

James McGovern has a habit of posing questions and then naming the people he would like to answer them. This time around, I had the privilege of having my name read out on the roll call. Actually he posted it just before I went on my week-long holiday hence I'm only getting around to it now.

Here are his questions (in blue) and my attempts at some answers (hopefully I don't sound like a complete fool - I'll settle for mildly foolish):

[JM] Protocols:Nowadays, the folks over at the Burton Group such as Bob Blakely, Dan Blum and Gerry Gebel have put together the most wonderful XACML interoperability events. The question that isn't addressed is if I am building an enterprise application from scratch, should I XACML-enabled, think about integrating with STS, stick to traditional LDAP invocation or something else?

[IY] I'm not 100% sure what James is asking and my answer will probably be different if James actually means something other than what I've interpreted it as. I read the question as being once the decision's been made to use XACML, how should one be dealing with authentication? Talking about an STS (I assume James means Security Token Service) vs LDAP refers to 2 different "layers". In reality nowadays, you're ultimately authenticating to a directory of some sort. Usually you do this using the LDAP protocol under the covers. Whether you know this or not depends on the overall design.

Note that using XACML means you are pushing policy definitions around to ultimately get your Policy Enforcement Point to be able to come up with an authorisation decision. When you talk about STS or LDAP, you're typically referring to authentication which ultimately produces some sort of credential for the user within their session. Authentication and authorisation (or entitlements as people seem to like calling it nowadays) are related, but separate things that can be implemented differently as long as there is a point where they interoperate. Usually the most important part is where the authentication mechanism passes the security principal onto the authorisation mechanism so it can make an identity based, access control decision (that is also hopefully fine grained and context aware).

That said, I'm going to ignore the XACML consideration for a moment...

There are a few common approaches to take when writing authentication for applications:
1) Take a service-oriented approach (e.g. SOA or web services)
2) Leverage an API or application programming standard (e.g. JNDI, JAAS)
3) Use the native protocol of the authentication store (e.g. LDAP, SQL)

Option 1 is the most difficult to set up because this type of infrastructure is typically not built in organisations today. But it IS the most extensible option and hides the implementation specifics from every application that needs to perform authentication. Whether the underlying store is a directory, database, file system or even a mainframe does not matter. You also get the benefits served up by leveraging a web service. For example, you just need to know how to format your message (this is actually not a problem if you use a standard as it is usually taken care of by some other service) and where to send your request (via the URI). You obviously also need network connectivity to that location. There are no headaches around what libraries to import, whether your authentication services are co-located with your application or whether you need to go screw around with configuration settings and files because you are actually calling a service that is not located on the same application server as you. Keep in mind that you don't necessarily have to use an STS, although it is probably the best approach today if you're going with a service-oriented design.

Option 2 still leverages standards of sorts. JNDI and JAAS for example are both standards in their own rights. They just happen to be tied into a programming language and platform. This option is probably still easier than option 1 because organisations will more than likely have this infrastructure more or less set up. It's a matter of getting the programmers to code to these standards/APIs and then setting up the application infrastructure to hook into the relevant authentication stores. Again, this is probably already done if you're using a standards-based Application Server (e.g. J2EE). You will however, have configuration files to screw around with and changes to any of the infrastructure will potentially require applications to be modified. You're also tied into the platform somewhat. For example, if you use JNDI you're stuck with Java and the directory under the covers. With a web service, it doesn't really matter what programming language is used or what the authentication store is. You can swap components out without modifying the other loosely coupled pieces. You're supposedly able to do this easily if you code to API standards, but that's rarely true. There's usually re-configuration and some re-writing required.

Option 3 requires intimate knowledge of the protocol or tools required to access the authentication store. If using LDAP, you need to know LDAP query syntax. If using SQL, you have to know how to write SQL queries or stored procedures. It also means you cannot change your authentication stores and schemas without re-writing your applications.

They each have their benefits, but it boils down to the age old discussion around tight coupling vs loose coupling. The looser the coupling of your infrastructure components, the more extensible they are. You lose performance however and it usually takes more effort and time to build a loosely coupled system because of all the design considerations to take into account. (Note: The performance issue is usually one that can be designed around if you have the budget. You put enough redundancy, load balancers and hardware in place and you can usually get something to perform within your service level agreements (SLAs). If your network hops are large, just do a better job of negotiating your SLAs - easier said than done I know).

Option 1 is the loosely coupled approach which should "identity proof" your environment for a longer period of time (notice I didn't say forever). Option 3 is the tightly coupled approach. Option 2 is something in between. The one to pick depends on requirements, time and cost constraints. The choice will be determined by how much of the authentication infrastructure specifics you want to burden your developers with.

Bringing the XACML considerations back into the picture, I would go for option 1. If you're going to take the effort and XACML-enable your applications, why would you "get cheap" and not go with the use of an STS? It also makes everything nice and clean from an application programming standpoint. Developers will only have to worry about using security services. They won't need to remember that for certain security related things, they need to use the web service while for others they have to use the API or go direct to the source over LDAP or SQL.

[JM] Virtual Directories: What role should a virtual directory play in an Identity metasystem? Should virtual directory be a standalone product in the new world and simply be a feature of an STS? If an enterprise were savage in consolidating all directory information into Active Directory, why would I still need virtualization?

[IY] I don't come across too many organisations that use a virtual directory. Maybe it says something about the maturity of their Identity Management infrastructure. Or maybe it means that they don't see the need and are quite happy replicating things using meta-directories and synchronisation.

Leveraging a virtual directory is very much a technology choice and dependent on each organisational environment. If they have lots of identity stores and have a nightmarish amount of information that would take a long time to integrate and synchronise, then a virtual directory makes sense. If an organisation has a fairly small number of stores or their strategy is to leverage a specific central store like Active Directory, then they probably don't. On the flip side, one could argue that the virtual directory could become this "central store".

I'm not for or against virtual directories. I just think there's a time, environment and place for the choice between a virtual directory or a synchronisation solution like a meta-directory. As for using a virtual directory as part of an STS, the argument is very similar to what I've just outlined.

[JM] Entitlements: One missing component of the discussion is authorization and their is somewhat too much focus on identity. Consider the scenario where if you were to ask my boss if I am still an employee, he would say yes as he hasn't fired me yet. Likewise, if you ask him what are all of the wonderful things I can access within the enterprise, he would say that he has no freakin clue, but as soon as you figure it out, please let him know. Honestly, even in my role, there are probably things that I can do but shouldn't otherwise have access to. So, the question becomes how come the identity conversation hasn't talked about any constructs around attestation and authorization?

[IY] People are too busy crapping on about OpenID and CardSpace all the time :-)

Seriously, I think it's got to do with the way things in the identity space evolve. Before you can deal with entitlements and attestation, you need to know who people are and what they can use (i.e. what they can "log into"). It's a very high level approach sure. But that's how organisations typically start looking at the whole issue.

Also, Identity Management is not an easy issue to solve. As a result, it's taken a long time to get around to thinking about authorisation properly. It doesn't mean we will never get there. We just have to be a little more patient. All the GRC initiatives going on around the place are certainly helping. Attestation is usually one of the first things that get addressed in any GRC initiative because it needs to be done to satisfy the regulators and auditors.

Once organisations realise that having a proper authorisation infrastructure in place makes their lives a lot easier from a management and audit perspective AND it'll save them money (instead of having to re-invent the authorisation wheel for every application), they'll start to do something about it.

It's also about evangelism, education and focus. The focus isn't there yet so there's no education. Evangelism comes from the industry as a whole. The large vendors are usually the ones with the marketing clout to get the messages out in a meaningful way. Unfortunately, they chase the dollars. Until recently, there hasn't been sufficient sales revenue or qualified opportunities to justify evangelising authorisation. It's the next cab off the rank I think. We might have to wait a year or 2 for organisations to get through the early phases of their GRC initiatives before authorisation gains real traction.

[JM] Workflow: Have you ever attempted to leave a comment on Kim Cameron blog? You will be annoyed with the registration/workflow aspects. The question this raises in my mind is what identity standards should exist for workflow? There are merits in this scenario for integrating with the OASIS SPML standard, but I can equally see value in considering BPEL as well.

[IY] I don't think there needs to be identity standards for workflow in the traditional sense of technical standards. A generic workflow standard (e.g. BPEL) across all disciplines is good enough and will be better in the long run. Workflows are very dynamic, can get very complex and will be different for each organisation even if they are trying to do similar things. This makes standards tricky. Then there is also workflow from a business standpoint. When technical folk talk standards, they usually mean nuts and bolts (e.g. XML specifications). Those in the business world don't care that a worklow is written in BPEL. They care that they have to write a frigging workflow procedure from scratch. They would probably find some standards around business process definitions useful. It might be prudent of us to define easily extensible procedural workflow templates for Identity business transactions perhaps? Now that would REALLY be something.

[JM] Education: Right now the conversation regarding identity is in the land of geeks and those who are motivated to read specifications. There is a crowd of folks who need things distilled, the readers digest version if you will. Traditionally, this role is served by industry analysts such as Gartner and Forrester. What would it take for this guys to get off their butts and start publishing more thoughtful information in this space?

[IY] I don't think industry analysts are ever going to write a "readers digest" version of anything related to Identity. It doesn't help them make more money from selling reports and holding conferences for specialised groups of people while charging them thousands of dollars each. Unfortunately, I think the fastest way to get simplified Identity education out there is through the marketing dollars of the large vendors. Consulting organisations (including analysts like Gartner and Forrester) will never simplify anything because they need for things to remain (or sound) complex so they can keep charging for their "expertise".

[JM]Conferences: When do folks think that the conversation about identity will occur at other than identity/security conferences? For example, wouldn't it have been wonderful if Billy Cripe, Craig Randall and Laurence Hart where all talking about the identity metasystem in context of ECM?

[IY] Ummm how about never...which is fine by the way. The Identity industry needs to make things so dead simple and ubiquitous that there is no need to talk about it. It should just be there. Therein lies the challenge facing us all today.

Paranoid about your passwords?

I came across this today. It's pretty handy if you are sick of trying to think of (and remember) complex passwords.

For those familiar with authentication schemes, it essentially blends the concept of challenge/response questions with passwords. The way I like to think of it is by using the following example...

The challenge (called "phrase" on the site) could be something like "what is my password for site x" and the response (called "password" on the site) is just a word you use as a "password key" so to speak. The site will spit out an actual password, which you can use as your real password for whatever site you use it for.

Metaphorically, it's like going to a locker (perhaps at an airport or a train station) to get your house keys so you can go home. Thankfully, you only have to go to a website instead of navigating through traffic or the public transport system to get your house keys.

Apparently there's no "magic" behind how it generates your password for you. Read about it here.

It's not foolproof, but it's certainly better than using a weak, simple password because it's better than single factor authentication. I wouldn't go as far as calling it a 2 factor authentication mechanism because using the traditional definition requires that the authenticating site handle the authentication factors directly and that the authentication factors are two out of the following three: something you know (e.g. password), something you have (e.g. smartcard), something you are (e.g. fingerprint).

But if you think about it, handling your password this way requires that you know something (what challenge/response combination to use) and also generates you a "token" of sorts (usually this comes from something you have - in this case, you could argue that this is the website). I know it's the same token each time so it's effectively a password but it's not something that's easy to guess. One could view it as a "pseudo token" that is generated based on knowledge that you have. Call it 1.5 factor authentication if you like. Or maybe "obscured/indirect authentication". Can anyone think of a better name? In any case, I'm really stretching the multi-factor definition here. But hopefully you know what I'm getting at. In short, it's better.

It's a very simple concept (now we can all say "crap why didn't I think of that") and a good one I think if you want to add that extra little bit of security to your everyday passwords.