Tag Archives: Strong Authentication

Next war on passwords

Google is the latest vendor to try to slay the password beast. I wish them the best, I really do. But password authentication hasn’t been the defacto security for this long without a reason.

Still, if any vendor has a shot it’s Google.

Cheap and easy

Mark Dixon has an excellent point in this post on why we still use passwords:

It was ease of use, not a technology-driven obsession with safety,  that led to wide adoption of the seat belt.

I think we face the same thing with passwords.   Intellectually, it is simple to understand why we should get rid of passwords.   However, in practice, widespread adoption will be triggered more by ease of use than perception of safety.  When an easier method for authentication emerges, people will adopt it – not because it is safer, but because it is easier.  If that easier method is also more secure, voila!  We will have achieved our desired result.

While I agree with Mark’s point, there is an important distinction that is not getting made in this discussion, the difference between personal and professional accounts. And this distinction goes right to the heart of Mark’s argument.

For personal accounts (for example your Facebook, Yahoo, LinkedIn, or Twitter account) ease of use is the single biggest driver. People will not, in general, use another authentication technique that isn’t as easy as passwords. Actually it has to be easier than passwords by an order of magnitude or it won’t displace the incumbent technology. It also has to be understandable to the average user so they believe that it really is secure (one could argue this is really just another aspect of ease of use). Try explaining client certificate authentication to your grandmother if you don’t believe me.

Also, the sensitivity of the account really makes little difference. Most users won’t treat their on-line banking account any different than their Facebook account. Bank of America offers a SecureID option for their on-line banking. That should be a no-brainer right? I don’t have any numbers but I would be shocked if they were getting anywhere north of %1 adoption of SecureID by their customers.

For professional accounts (your PC, enterprise resources, or hosted service account) ease of use is not the primary driver, cost is. Cost is understood by most enterprises to mean the monetary cost of your credential plus the measurable cost to support you using it. I used the word “measurable” for a reason. Most companies don’t care how hard it is for you to understand and use a specific authentication mechanism if you are a salaried employee. That cost is hidden to them. On the other hand the cost to the company for you to call the help desk if you have an authentication problem is measurable and tracked along with the cost to issue new credentials when needed.

For both personal and professional accounts, passwords rule the roost because they are easy to use, cheap to deploy, cheap to support, and easy to understand.

But if an authentication mechanism becomes popular that is cheap to deploy and support, it may have a chance to displace passwords for professional accounts.

Only 48 percent of organizations paying any attention at all

In a related note, this story about a Quest sponsored Aberdeen study indicates that 52 percent of organizations do not require strong authentication to access sensitive data:

Quest Software, Inc. underwrote an Aberdeen Group benchmark study, “Strong User Authentication,” which shows that 52 percent of organizations require only passwords for employees to access critical data, rather than augmenting passwords with stronger forms of authentication such as hardware tokens, digital certificates or risk-based scoring. Nearly 150 organizations from a diverse set of global industries were polled for the study.

Other key findings of the Aberdeen benchmark study include:

  • 88 percent of enterprise users have multiple work-related passwords, averaging between five and six
  • 64 percent of organizations do not even require users to change their passwords
  • 45 percent of organizations allow standard dictionary terms (like “password”)
  • 29 percent of organizations have no requirements for password length

None of these stats surprise me.

Jackson Shaw of Quest is quoted in the article as well:

“With the recent, well-publicized incidents of network and identity theft, companies need to put security first and require more than just passwords for user authentication,” said Jackson Shaw, senior director, product management, Quest Software. “Helping our customers increase security and mitigate the risk associated with compromised confidential information has become a top priority at Quest. As a result, Quest offers solutions for two-factor authentication as well as single sign-on, provisioning, password management, role management, auditing and compliance reporting.”

I’m not sure what Quest product Jackson is referring to as far as provisioning. Perhaps he is referring strong authentication credential provisioning.  Aside from that, it’s a very interesting article.

What’s my motivation?

William Vambenepe has some keen observations about requirements here in this post about Cloud computing:

There are three types of user requirements. The Animoto use case is clearly not in the first category but I am not convinced it’s in the third one either.

  1. The “pulled out of thin air” requirements that someone makes up on the fly to justify a feature that they’ve already decided needs to be there. Most frequently encountered in standards working groups.
  2. The “it happened” requirements that assumes that because something happened sometimes somewhere it needs to be supported all the time everywhere.
  3. The “it makes business sense” requirements that include a cost-value analysis. The kind that comes not from asking “would you like this” to a customer but rather “how much more would you pay for this” or “what other feature would you trade for this”.

When cloud computing succeeds (i.e. when you stop hearing about it all the time and, hopefully, we go back to calling it “utility computing”), it will be because the third category of requirements will have been identified and met. Best exemplified by the attitude of Tarus (from OpenNMS) in the latest Redmonk podcast (paraphrased): sure we’ll customize OpenNMS for cloud environments; as soon as someone pays us to do it.

I can absolutely attest to point number one as it pertains to standards groups. But its point number three that I wanted to highlight as it relates to a theme I have been discussing a lot lately. Namely that IdM is messy because enterprise software vendors in general won’t externalize identity in their products beyond AD authentication.

Now I am not implying that enterprise software vendors are lazy. Rather it’s a matter of priorities. Enterprise software vendors typically have a backlog of feature requests and fixes that they need to work on. The ones that they get asked for the most, or that they feel will give them competitive advantage, that will get the priority.

Like William says, it’s not whether the customer wants a feature, but how much are they willing to pay for it and what other features would they give up in exchange.

Dave Kearns believes that if there is an IdM roadmap laid down, vendors that implement it will “reap the rewards” and those that don’t will be destined for “where are they now”. Perhaps Dave is right. But history shows us quite the opposite. Look at strong authentication for example. Despite dramatic reductions in cost and increased options, despite all the experts’ advice, and the presence of a solid roadmap, the vast majority of authentication in enterprises is password-based. And very little enterprise software supports strong authentication out-of-the-box.

So what will it take to spur enterprise vendors to support externalized identity? I really don’t know. Yet.