Granted, no one is saying FIDO is the silver bullet for two-factor authentication. However, I get the impression that many people (and many senior executives in particular…) are thinking or at least hoping that maybe it is. With the goal of putting FIDO into the proper perspective, this blog will go over some of the things Gluu loves about FIDO, and some of its limitations.
One of the most exciting potentials for FIDO is the opportunity to bring down the cost of USB-based and bio-metric authentication. Right now, USB authentication tokens are just too expensive. With the FIDO U2F standards, more manufacturers producing more creative form-factors for tokens is a win-win for consumers–fun-to-use devices at a lower price. Likewise, FIDO also promises to standardize biometric authentication through its UAF standards–why should each biometric vendor have a proprietary interface? For example, where are the API’s for fingerprint authentication for the new Samsung Galaxy S5?
In the near term, where will you be able to use a FIDO authentication mechanism? A plugin for Chrome and Firefox is in the works, but the roadmap for Android support of FIDO is unclear. Also, the U2F standard is USB protocol hardwired. On a phone without a USB interface, its useless. Currently, the FIDO website FAQ says:
While there are no current product announcements, we anticipate multiple FIDO options available on Android phones this year and development with Windows tablet and Apple products shortly thereafter. Check in with us in a few months.
Of course, USB and biometric authentication are just two ways you could identify a person. There are other cognitive, behavioral, PKI, and NFC mechanisms that also make sense in many situations. In my SXSW prezi I present over thirty different mechanisms to identify a person. And this number probably represents less than 10% of the technologies available to organizations. For many organizations, FIDO will be just one of many authentication mechanisms that are supported. In fact, using FIDO only makes sense if the person has a certain kind of device in their hands.
One aspect of website authentication that many organizations don’t understand is that identifying the person is just one step in the workflow for authentication. Even assuming a positive authentication is made, many websites consider a number of contextual clues to assist in fraud detection. Is the geo-location of the IP address in a foreign country? Are there hooks to intrusion detection, central logging, or threat information sharing services? Authentication is a critical event frequently with special business logic required by the organization. The mechanism of authentication–which may be FIDO–is just one part of that business logic.
Recently, there was a Microsoft study that surveyed many different types of authentication. What it found is that while some mechanisms were more secure, and some more usable, the main impediment to the adoption of two-factor were deployment challenges. Will FIDO improve deployability of 2FA? Not significantly. Will it make USB and biometric authentication cheaper? YES!
One of the conundrums we are facing is why is FIDO getting all the attention, while OpenID Connect’s delivery of a final specification has been for the most part un-noticed. At first glance, federation protocols like “Connect” don’t seem to provide a solution for two-factor authentication. In fact, Connect is neutral on how the person is authenticated.
However, here at Gluu we see everything around authentication as having the greatest impact on deploy-ability. In order to get developers of mobile applications and websites to support strong authentication, we need a lingua franca. App developers want to be able to select FIDO authentication, or phone authentication, or even password authentication–depending on the situation. Tightly bundling an application to a low-level authentication protocol like FIDO would be just as bad as sending the username / password SELECT statement to the database. OpenID Connect provides a higher level interface between the application and the domain that is authenticating the person.
In order to reduce the deployment challenge of strong authentication, we need to make it brain dead easy for developers who are writing custom applications, and for system administrators who are configuring off-the-shelf enterprise software and SaaS services. Don’t get me wrong, FIDO is great. But it is possible that the FIDO standards will primarily be used in an organization’s federation platform–not directly in its applications.
One last thought: strong authentication is only a partial success. The trick is… knowing when to elevate from a less secure type of authentication, or when to “step-up” authentication. To specify the authentication policies for API’s , an authorization protocol like the User Managed Access protocol is needed. If we design only for strong authentication and SSO, we will be setting the bar too low.
Subscribe to Get News and Product Updates
our RSS Feed