Joerg Resch at Kuppinger Cole points us to new research showing  how social networks can be used in conjunction with browser leakage to provide accurate identification of users who think they are browsing anonymously.

Joerg writes:

Thorsten Holz, Gilbert Wondracek, Engin Kirda and Christopher Kruegel from Isec Laboratory for IT Security found a simple and very effective way to identify a person behind a website visitor without asking for any kind of authentication. Identify in this case means: full name, adress, phone numbers and so on. What they do, is just exploiting the browser history to find out, which social networks the user is a member of and to which groups he or she has subscribed within that social network.

The Practical Attack to De-Anonymize Social Network Users begins with what is known as “history stealing”.  

Browsers don’t allow web sites to access the user’s “history” of visited sites.  But we all know that browsers render sites we have visited in a different color than sites we have not.  This is available programmatically through javascript by examining the a:visited style.  So malicious sites can play a list of URLs and examine the a:visited style to determine if they have been visited, and can do this without the user being aware of it.

This attack has been known for some time, but what is novel is its use.  The authors claim the groups in all major social networks are represented through URLs, so history stealing can be translated into “group membership stealing”.  This brings us to the core of this new work.  The authors have developed a model for the identification characteristics of group memberships – a model that will outlast this particular attack, as dramatic as it is.

The researchers have created a demonstration site that works with the European social network Xing.  Joerg tried it out and, as you can see from the table at left, it identified him uniquely – although he had done nothing to authenticate himself.  He says,

“Here is a screenshot from the self-test I did with the de-anonymizer described in my last post. I´m a member in 5 groups at Xing, but only active in just 2 of them. This is already enough to successfully de-anonymize me, at least if I use the Google Chrome Browser. Using Microsoft Internet Explorer did not lead to a result, as the default security settings (I use them in both browsers) seem to be stronger. That´s weird!”

Since I’m not a user of Xing I can’t explore this first hand.

Joerg goes on to ask if history-stealing is a crime?  If it’s not, how mainstream is this kind of analysis going to become?  What is the right legal framework for considering these issues?  One thing for sure:  this kind of demonstration, as it becomes widely understood, risks profoundly changing the way people look at the Internet.

To return to the idea of minimal disclosure for the browser, why do sites we visit need to be able to read the a:visited attribute?  This should again be thought of as “fingerprinting”, and before a site is able to retrieve the fingerprint, the user must be made aware that it opens the possibility of being uniquely identified without authentication.

Not five minutes after pressing enter on my previous post a friend wrote back and challenged me to compare IE’s behavior with that of Firefox.  I don’t like doing product comparisons but clearly this is a question others will ask so I’ll share the results with you:

Results:  behavior of the two browsers are essentially identical.  In both cases, my browser was uniquely identified.

Conclusion:  we need to work across the industry to align browsers with minimal disclosure principles.  How much information needs to be released to a site we don’t trust yet?  To what extent can the detailed information currently release be collapsed into non-identifying categories?  When there is some compelling reason to release detailed information, how do we inform the user that the site wants to obtain a fingerprint?

Slashdot’s CmdrTaco points us to a research project announced by EFF’s Peter Eckersley that I expect will provoke both discussion and action:

What fingerprints does your browser leave behind as you surf the web?

Traditionally, people assume they can prevent a website from identifying them by disabling cookies on their web browser. Unfortunately, this is not the whole story.

When you visit a website, you are allowing that site to access a lot of information about your computer’s configuration. Combined, this information can create a kind of fingerprint - a signature that could be used to identify you and your computer. But how effective would this kind of online tracking be?

EFF is running an experiment to find out. Our new website Panopticlick will anonymously log the configuration and version information from your operating system, your browser, and your plug-ins, and compare it to our database of five million other configurations. Then, it will give you a uniqueness score - letting you see how easily identifiable you might be as you surf the web.

Adding your information to our database will help EFF evaluate the capabilities of Internet tracking and advertising companies, who are already using techniques of this sort to record people’s online activities. They develop these methods in secret, and don’t always tell the world what they’ve found. But this experiment will give us more insight into the privacy risk posed by browser fingerprinting, and help web users to protect themselves.

To join the experiment:
http://panopticlick.eff.org/

To learn more about the theory behind it:
http://www.eff.org/deeplinks/2010/01/primer-information-theory-and-priva…

Interesting that my own browser was especially recognizable:

I know my video configuration is pretty bizarre - but don’t understand why I should be broadcasting that when I casually surf the web.  I would also like to understand what is so special about my user agent info. 

Pixel resolution like 1435 x 810 x 32 seems unnecessarily specific.  Applying the concept of minimal disclosure, it would be better to reveal simply that my machine is in some useful ”class” of resolution that would not overidentify me.

I would think the provisioning of highly identifying information should be limited to sites with which I have an identity relationship.  If we can agree on a shared mechanism for storing information about our trust for various sites (information cards offer this capability) our browsers could automatically adjust to the relationship they were in, releasing information as necessary.  This is a good example of how a better identity system is needed to protect privacy while providing increased functionality.

Now that the world is so thoroughly post-modern, how often do you come across information that qualifies as unexpected?  Well, I have to say that the following story , appearing in the The Australian, left me wide-eyed:

Yesterday, in the church of the City of London Corporation, (Canon Parrot)  presented an updated version of Plow Monday, an observance that dates from medieval times. On this day, the first Monday after Twelfth Night, farm labourers would bring a plough to the door of the church to be blessed.

“When I arrived a few months ago I looked at this service and thought, ‘Why do we have a Plow Monday?’,” Canon Parrott said. Men and women coming to his church no longer used ploughs; their tools were their laptops, their iPhones and their BlackBerries.

So he wrote a blessing and strode out to deliver it before a congregation of 80, the white heat of technology shining from his every pronouncement. “I invite you to have your mobile phone out … though I would like you to put it on silent,” he said.

This was Church 2.0. Behind him, the altar resembled a counter at PC World. Upon it, laid out like holy relics, were four smart phones, one Apple laptop and one Dell.

Then, after another hymn, came the blessing of the smart phones. The Lord Mayor of London offered his BlackBerry to Canon Parrott, which was received with due reverence and placed upon the altar.

The congregation held their phones in the air, and Canon Parrott addressed the Almighty. “By Your blessing, may these phones and computers, symbols of all the technology and communication in our daily lives, be a reminder to us that You are a God who communicates with us and who speaks by Your Word. Amen.”

It makes me wonder what Innis said to McLuhan when he read abut this.

Le Figaro carried a report of an additional prayer, “”May our tongues be gentle, our e-mails be simple and our websites be accessible”. 

Perhaps it is asking too much, but I would have really liked Father Parrott to add, “websites be accessible and secure.”  After all - it can’t hurt.   Perhaps next time?

Steve Riley at Amazon takes a fascinating and non-ideological approach on his new blog.  The combination will keep me tuned in - I expect others will feel the same way.  He writes:

“As I’ve talked with customers who have deployed or plan to deploy Windows Server 2008 instances on Amazon EC2, one feature they commonly inquire about is Active Directory Federation Services (ADFS). There seems to be a lot of interest in ADFS v2 with its support for WS-Federation and Windows Identity Foundation. These capabilities are fully supported in our Windows Server 2008 AMIs and will work with applications developed for both the “public” side of AWS and those you might run on instances inside Amazon VPC.

“I’d like to get a better sense of how you might use ADFS. When you state that you need “federation,” what are you wanting to do? I imagine most scenarios involve applications on Amazon EC2 instances obtaining tokens from an ADFS server located inside your corporate network. This makes sense when your users are in your own domains and the applications running on Amazon EC2 are yours.

“Another scenario involves a forest living entirely inside Amazon EC2. Imagine you’ve created the next killer SaaS app. As customers sign up, you’d like to let them use their own corpnet credentials rather than bother with creating dedicated logons (your customers will love you for this). You’d create an application domain in which you’d deploy your application, configured to trust tokens only from the application’s ADFS. Your customers would configure their ADFS servers to issue tokens not for your application but for your application domain ADFS, which in turn issues tokens to your application. Signing up new customers is now much easier.

“What else do you have in mind for federation? How will you use it? Feel free to join the discussion. I’ve started a thread on the forums, please add your thoughts there. I’m looking forward to some great ideas.”

I really look forward to this.  Let’s see where it goes…  

Given the mail I get from mutual customers, I know Steve will end up with some interesting insights.

Internet security is a sitting duck that could easily succumb to a number of bleak possible futures.

One prediction we can make with certainty is that as the overall safety of the net continues to erode, individual web sites will flail around looking for ways to protect themselves. They will come across novel ideas that seem to make sense from the vantage point of a single web site. Yet if they implement these ideas, most of them will backfire. Internet users have to navigate many different sites on an irregular basis. For them, the experience of disparate mechanisms and paradigms on every different site will be even more confusing and troubling than the current degenerating landscape. The Seventh Law of Identity is animated by these very concerns.

I know from earlier exchanges that Michael Ramirez understands these issues – as well as their architectural implications. So I can just imagine how he felt when he first encountered a new system that seems to represent an unfortunately great example of this dynamic. His first post on the matter started this way:

“Logging into the DFAS myPay site is frustrating. This is the gateway where DoD employees can view and change their financial data and records.

“In an attempt secure the interface (namely to prevent key loggers), they have implemented a javascript-based keyboard where the user must enter their PIN using their mouse (or using the keyboard pressing tab LOTS of times).

“A randomization function is used to change the position of the buttons, presumably to prevent a simple click-tracking virus from simply replaying the click sequence. Numbers always appear on the upper row and the letters will appear in a random position on the same row where they exist on the keyboard (e.g. QWERTY letters will always appear on the top row, just in a random order).

“At first glance, I assumed that there would be some server-side state that identified the position of the buttons (as to not allow the user’s browser to arbitrarily choose the positions). Looking at how the button layout is generated, however, makes it clear that the position is indeed generated by the client-side alone. Javascript functions are called to randomize the locations, and the locations of these buttons are included as part of the POST parameters upon authentication.

“A visOrder variable is included with a simple substitution cipher to identify button locations: 0 is represented by position 0, 1 by position 1, etc. Thus:

“Thus any virus/program can easily mount an online guessing attack (since it defines the substitution pattern), and can quickly decipher the PIN if it has access to the POST parameters.

“The web site’s security implementation is painfully trivial, so we can conclude that the Javascript keyboard is only to prevent keyloggers. But it has a number of side effects, especially with respect to the security of the password. Given the tedious nature of PIN entry, users choose extremely simplistic passwords. MyPay actually encourages this as it does not enforce complexity requirements and limits the length of the password between 4 and 8 characters. There is no support for upper/lower case or special characters. 36 possible values over an 4-character search space is not terribly secure.”

A few days later, Michael was back with an even stranger report. In fact this particular ”user journey” verges on the bizarre. Michael writes:

“MyPay recently overhauled their interface and made it more “secure.” I have my doubts, but they certainly have changed how they interact with the user.

“I was a bit speechless. Pleading with users is new, but maybe it’ll work for them. Apparently it’ll be the only thing working for them:

Although most users have established their new login credentials with no trouble, some users are calling the Central Customer Support Unit for assistance. As a result, customer support is experiencing high call volume, and many customers are waiting on hold longer than usual.

We apologize for any inconvenience this may cause. We are doing everything possible to remedy this situation.

Michael concludes by making it clear he thinks “more than a few” users may have had trouble. He says, “Maybe, just maybe, it’s because of your continued use of the ridiculous virtual keyboard. Yes, you’ve increased the password complexity requirements (which actually increased security), but slaughtered what little usability you had. I promise you that getting rid of it will ‘remedy this situation.’”

One might just shrug one’s shoulders and wait for this to pass. But I can’t do that.  I feel compelled to redouble our efforts to produce and adopt a common standards-based approach to authentication that will work securely and in a consistent way across different web sites and environments.  In other words, reusable identities, the claims-based architecture, and truly usable and intuitive visual interfaces.

Earlier this week I presented the Identity Keynote at the Microsoft Professional Developers Conference (PDC) in LA.  The slide deck is here, and the video is here.

After announcing the release of the Windows Identity Foundation (WIF) as an Extension to .NET, I brought forward three architect/engineers to discuss how claims had helped them solve their development problems.   I chose these particular guests because I wanted the developer audience to be able to benefit from the insights they had previously shared with me about the advantages - and challenges - of adopting the claims based model.  Each guest talks about the approach he took and the lessons learned.

Andrew Bybee, Principal Program Manager from Microsoft Dynamics CRM, talked about the role of identity in delivering the “the Power of Choice” - the ability for his customers to run his software wherever they want, on premises or in the cloud or in combination, and to offer access to anyone they choose.

Venky Veeraraghavan, the Program Manager in charge of identity for SharePoint, talks about what it was like to completely rethink the way identity works in Sharepoint so it takes advantage of the claims based architecture to solve problems that previously had been impossibly difficult.  He explores the problems of ”Multi-hop” systems and web farms, especially the “Dreaded Second Hop” - which he admits “really, really scares us…”  I find his explanation riveting and think any developer of large scale systems will agree.

Dmitry Sotnikov, who is Manager of New Product Research at Quest Software, presents a remarkable Azure-based version of a product Quest has previously offered only “on premise”.  The service is a backup system for Active Directory, and involved solving a whole set of hard identity problems involving devices and data as well as people.

Later in the presentation, while discussing future directions, I announce the Community Technical Preview of our new work on REST-based authorization (a profile of OAuth), and then show the prototype of the mutli-protocol identity selector Mike Jones unveiled at the recent IIW.   And finally, I talk for the first time about “System.Identity”, work on user-centric next generation directory that I wanted to take to the community for feedback.  I’ll be blogging about this a lot and hopefully others from the blogosphere will find time to discuss it with me.

I’ve sometimes been of two minds about OpenID.  I’ve always seen it as alluring because of its simplicity and openness.  It seemed perfect for simple web applications.

But in my darker moments, I worried about some of the system’s usability and security issues.  In particular, I was concerned about how easy it would be for an “evil site” to trick users into going to a web site that looks identical to their OpenID provider, convincing them to log in, and then stealing their credentials.  If this were to happen, everything that is good about OpenID would turn into something negative.

OpenID has become a key part of the Identity Metasystem

I think many of us involved with the OpenID community came to the same conclusions, but felt that if we kept trying to move adoption forward, we’d be able to figure out how to solve the problems.  In the last year, OpenID has without doubt become the most widely adopted system for reusable internet identity.  Adoption by destination sites continues to grow dramatically: approximately 50,000 sites as of July 1, 2009.  The big Internet properties like Google, Yahoo, AOL, MySpace, and Windows Live have become (or are becoming) OpenID Providers.   As a result, the vast majority of the online US population has an account that can be used to log in at the growing number of destination sites. 

Maybe even more important, some of these sites are of the kind that can quickly change perception and behavior. 

Most notable is Facebook, which took a huge step forward when it started accepting OpenIDs for login - blowing away the old saw that “no one wants to be a relying party”. 

Now, the US Government has decided to adopt OpenID as one of the identity protocols for citizen interaction - again, as Relying Party, not Identity Provider.

Sea Change

There is a sea-change here.  I strongly believe the right thing to do is get  behind OpenID as part of the Identity Metasystem, help promote adoption, and work with the community to make it safer and easier to use.  What is encouraging is that the community has repeatedly shown its ability to evolve as it deploys, and has been able to rapidly extend the standard from the inside.   It has now become widely recognized in the industry that active client software (also called an “Identity Selector”) for OpenID could solve most of its problems, given some minor revisions or additions to the protocol.  By remembering the identities you use, this kind of software can address two sets of issues:

• Usability:  Lets you bring your identities with you to the site, rather than the site having to guess what identities you have
• Security:  Protects you from being sent to a malicious site impersonating a real site that would steal your password

New prototype at IIW

Yesterday at the OpenID Summit hosted by Yahoo, Microsoft’s Mike Jones and Ariel Gordon  showed some of the work their team has been doing to help figure out how this kind of capability could work.  What’s cool is that the client they were showing is completely optional - without it, OpenID continues to work as it currently does.  But with it, experience improves and the dangers are greatly reduced.  I agree with them that demand for a better and safer OpenID user experience will drive selector adoption, which will in turn enable scenarios at higher levels of assurance than are possible with OpenID today.

Ariel Gordon, the main UX designer, told me, “I see it as a starting point for joint work with others in the community - definitely not a finished solution or product.”

It is consistent with the Information Card metaphor:

• Your OpenIDs are shown as visual cards
• You select an OpenID by clicking
• The OpenID last used at the site is the default selection

New OpenIDs can be added on the fly, by picking one from a list suggested by the site, or by typing the provider’s URL.

Mike made a good point about what this means for people who use smaller OpenID providers:  “The cool thing is that it remembers the OpenIDs you’ve used and where you used them […] With a web-based Nascar user interface, Arizona Sate University users will never get the same user experience that Google.com users get […]”

Good Tweets

Unfortunately I couldn’t attend the meeting in person but remained wired to the tweets.  Summit host Allen Tom from Yahoo said, “Showing already used OpeniIDs is a great protection against phishing: if a rogue RP tries to send the user to ‘fake yahoo.com’, a regular Yahoo user will click on his Yahoo button in the selector and won’t even see the fake yahoo link.”

He added, “The prototype selector goes in the right direction by offering a better experience when present, while not preventing users to access their favorite sites from any computer.”

Google’s Eric Sachs saw value too. “…And a fake yahoo tile would say “never used here” so that’s even more information to help protect the user.”

Bringing our perceptions together from different organizations with different missions and  vantage points is what can make all of this succeed. The partnering is the key.

So one of the best things about the prototype, in my view, is that it has already demonstrated collaboration between a whole set of really experienced community members:

• Relying Parties: JanRain, Plaxo, Deutsche Telekom
• OpenID Providers: Yahoo, Google, JanRain
• Identity Selectors: Microsoft, Deutsche Telekom
• Enhancing Specifications: Microsoft, Facebook, Yahoo. 

Today, the same prototype was presented to the influential Internet Identity Workshop .  I’ll add to my growing lis of IOU’s a promise to do a screen capture of how the prototype works so everyone can take a look.

John Fontana writes about the SAML interoperability test in ComputerWorld, turning quite a bit of his attention to Microsoft:

“Microsoft completed its first SAML interoperability test and the results are in: Active Directory Federation Services 2.0 software received a passing grade.

“Microsoft’s federated identity platform passed its first SAML 2.0 interoperability test with favorable marks, signaling the end to the vendor’s standoff against the protocol.

“The eight-week, multivendor interoperability workout conducted by the Liberty Alliance and the Kantara Initiative also resulted in passing marks for two other first-time entrants – SAP and Siemens. Return testers Entrust, IBM, Novell and Ping Identity also passed. Results were announced Wednesday.

“The Liberty Interoperable testing was a great opportunity to verify that Active Directory Federation Services (AD FS) 2.0 is interoperable with others’ SAML 2.0 implementations. This should give our customers confidence that their federation deployments using ADFS will ‘just work,’” says Conrad Bayer, product unit manager for federated identity at Microsoft.

“In the past, Microsoft has been dismissive of the Security Assertion Markup Language (SAML), a standard protocol for exchanging authentication and authorization data between and among security checkpoints, preferring the WS-Federation and other protocols it helped develop. The company previously supported the SAML token, but never the transport profiles of the protocol…

As much as I love John, I don’t think ”dismissive” really describes our attitude - at least I hope it doesn’t.  It is true that our initial thinking was that the world would be a ”tidier place” if people used one single protocol that worked both for “Active Clients” (e.g. applications that run on your PC or phone) and “Passive Clients” (web pages served up in a browser).  We saw WS-Federation as a way to achieve that technical symmetry.  But I and others have also said for several years that we saw much of what people were doing with SAML as being innovative and positive.  And we have made it very clear that an Identity Metasystem means “no silos”.  

Today you can see the results of this thinking in our new product.  ADFS V2 does everything it can to conform with the Identity Metasystem idea.  That means supporting SAML as well as the other Federation and Claims Transformation protocols (e.g. WS-Trust and WS-Federation). I think the synergy will be great for our customers and the industry.

John goes on to say: 

“Full matrix” testing means all participants must test against each other. The test was conducted over the Internet from points around the globe using real-world scenarios between service providers and identity providers as defined by the SAML 2.0 specification.

Microsoft participated in the testing with Active Directory Federation Services 2.0 (formerly code-named Geneva), which is slated to ship later this year. ADFS 2.0 is part of a larger identity platform that includes Windows Identity Foundation and Windows Cardspace.

Microsoft said earlier this year it would have SAML 2.0 certification before it released Geneva. The SAML profiles ADFS 2.0 supports cover the core features of federation.

ADFS 2.0 provides identity information and serves as a Security Token Service (STS), a transformation engine that is key to Microsoft’s identity architecture. ADFS lets companies extend Active Directory to create single sign-on between local network resources and cloud services.

[Read more here]