BrowserID a Threat to Individual Freedom?

The folks at Mozilla recently introduced BrowserID. You can compare it to OpenID, but there are some key differences. The basic idea - a single set of authentication credentials across multiple sites and simplified logon to each as facilitated by the browser. Ian Yip took an interesting look at BrowserID from the an Identity Management industry perspective and how it relates to what we call identity federation. For more details on how it works, check Lloyd Hilaiel's post.

But that's not what I wanted to write about. I'm more interested in SC Magazine's article headlined Mozilla BrowserID "seriously flawed" and Roger Clarke's Reaction to Mozilla's BrowserID Proposal, which was the subject of the SC Mag article. My first point is simply: go read it. It gives you a lot to think about. My second point, though, is a little more complex.

Clarke makes some interesting and compelling arguments about Internet privacy and individual freedom. I can't say that his logic is incorrect or that his points are invalid, because they're not. But his anger (characterized by phrases like "seriously flawed 'identity management' schemes" and "its design is seriously threatening to individual freedoms") may be a bit misplaced.

I agree with Richard that BrowserID is not THE solution to solve the Internet's authentication and privacy problem. But that's not the challenge that Mozilla has sought to solve. Not every site that requires a logon is a major privacy risk. I have probably 50 or more web site accounts to manage and I welcome solutions to my credential management problem. I'm a security guy but I will gladly introduce some level of risk to make life easier when browsing a large number of those sites. We all do to a degree. e.g.) It's less risky to go to a library anonymously to look something up in a book but the Internet at home is just so much more convenient that we risk being eavesdropped or introducing malware to our systems every time we use it.

It reminds me of the old argument that two-factor authentication is useless because it's susceptible to MITM attacks. BrowserID won't be a silver bullet for all authentication scenarios and maybe not even for ANY scenarios that require high security or strong assertions about the user, but it could still be a useful way for end-users who want to simplify the logon process. Claiming that BrowserID is seriously flawed because it doesn't address issues outside of its own scope just seems wrong and even somewhat irresponsible. The IT industry's version of media sensationalism maybe?

I don't mean to pick on SC Mag - the title got me to read Richard's article, which is the purpose of a strong title, but I'm pulling for one of these solutions (OpenID, CardSpace, BrowserID) to make it into the mainstream so that my life will be a little easier. And creating hysteria and FUD around them doesn't help with user adoption.

DIDW 2008

I saw, heard, and did a lot of interesting things this week at DIDW in Anaheim.

First, thank you Ping Identity for a good mid-week party at the HoB. (We should all publicly thank Ping and give them reason to continue hosting such events.)

We had a bloggers meet-up, though you won't hear too many others talk about that (maybe Ash). I did get to meet a number of folks who I've only previously met online. And I had many good conversations.

I heard more about the consulting (and other) capabilities of companies like Identropy, CoreBlox, and Optimal IdM – all worth a conversation if you need some Identity consulting help. And each has unique strengths. I wonder if you would all benefit from some kind of cooperative network rather than having the perception of competition. I'll have to think about that.

We gave away a lot of sticky eye balls. One became known as the eye in the sky.

I learned about important things like:

• The Identity Assurance Framework
• Marty's Identity Model
  (with which more of us should be helping)

And heard a lot of interesting discussions and tidbits, including:

• The US Treasury Dept transfers more than $1 Billion each day via PKI
• There seems to be consensus that enterprises will be affected by market forces on consumer identity and Web 2.0. ...perhaps TPS reports will be replaced by Twitter.
• Searching on "Identity Management" has declined throughout 2006, 2007, and 2008. My own research reveals that searching on "Microsoft", "Oracle" and "Active Directory" have all declined at a similar rate. So, it may mean nothing.
• One interesting case for synchronization vs. virtualization: If you front-end data that you don't own (and therefore can't control), you should replicate data and sync rather than using a totally virtual approach. It sounded like someone learned that the hard way.
• Not all Virtual Directories are created equal. I heard a panelist ask vendors for a feature that I know exists in at least two Virtual Directory products.
• Virtual Directories might be able to fill a gap in the real-time link between physical and logical security (grant access only when employee is swiped in).

On the flight back, a crazy thing happened. I heard a horrible scream outside the window of the airplane and when I looked outside, I saw something that seemed to be flying past us at a close distance. I quickly grabbed my camera and got a shot of it. (OK - you probably had to be at DIDW to appreciate that.) If you weren't, use this short waste of your time as inspiration to go check out Symplified and see what they're doing with SaaS-based Web Access Management. Pretty cool stuff. Their model removes a lot of the pain that gave Identity Management a bad name in its early days. And no, that's not Che.

I guess that's it for my DIDW update. For now.

Single Sign-On; Multiple Confusion Points

The Identity Management landscape is littered with various products. It's already difficult to understand IdM product categories and how they work together. But it's made worse because various vendors implement their technologies differently. That's not necessarily a bad thing in itself, but customers are confused.

The problem is analogous to that of Microsoft's Internet Information Services (IIS). IIS is both a web server and an application server. So, in a chart, it would line up against the Apache and Sun web servers. But, it would also line up against Tomcat, WebSphere and WebLogic in the application server category. This same phenomenon occurs often with Identity Management products. Some products have single capability and others have multiple. Some companies offer a single product and others offer multiple. So, it becomes very difficult to compare apples to apples.

In protest of all this confusion, I continue to attempt to simplify the IdM landscape. A while ago, I tried to create an identity services architecture map that could be used as a visual aide when communicating about where products fit in to an overall IdM architecture. While not 100% satisfied with it, I do think it serves the basic purpose.

Lately though, I've been re-thinking Web SSO and Enterprise SSO. What I've found is that people tend to group them together. However, at their core these are two very different technologies.

Web SSO is about securing access. It's generally implemented as a web server filter that intercepts access requests and makes decisions about whether to grant or deny access to the requested resource for the requesting party. Strong Web SSO products typically include a mechanism to manage web resources and user access permissions.

ESSO, on the other hand, is about enabling a better end-user experience. Typically, ESSO is implemented as a desktop client that manages user credentials on behalf of a single user. There are some ESSO implementations that act as an access proxy somewhere on the network, but this functionality isn't core to ESSO capabilities. The main driver of ESSO tends to be end-user experience and not security. In fact, I often hear the ESSO question from customers posed something like this:

We want ESSO to make users' lives easier, but we're afraid of the security implications. If a password is compromised, an attacker would now have access to the entire kingdom.

My answer is that this problem isn't with ESSO -- it's a problem with the authentication mechanism. Two-factor authentication would prevent an attacker from accessing anything with just a password compromise. And ESSO enables strong password policies on applications throughout the enterprise, which means passwords are much less likely to become compromised in the first place. If users don't ever need to remember or manually enter their passwords into systems, you could reasonably require 10 character passwords which require upper, lower, numeric and special characters. And you can force a password change every 30 days (this can also be transparent to the end-user). This creates a password that's much more difficult to guess or brute-force attack than a typical user's 6- or 8- digit alpha-numeric password.

So, I guess I'm thinking that I might move ESSO out of the Access Services layer and into the User Services layer. It's really not doing any enforcement and it's not managing policies or access rights. It's really only fostering a better user experience in a secure way.

And let's just all start ignoring the term Reduced SSO. This term just acknowledges that not every enterprise system can participate in an SSO implementation. Is this really necessary to distinguish? We're looking to achieve single sign on for participating applications. Let's not confuse customers further with an additional term that only points out what should already be obvious. If we can make this all simpler, I think we'll see higher adoption (and success) rates and happier customers.