Archive for the 'Phishing Resistance' Category

February 20, 2013
An update on our war against account hijackers

I recommend reading Google’s post An update on our war against account hijackers. It describes the kinds of measures taken by professionally-run Identity Providers to defend against account takeover.

A message not stated but implied is that consumers and Web sites are far better off depending upon identities provided by organizations with the resources and dedication to successfully fight takeover attempts. Sites with their own username/password login systems without these defenses are vulnerable, and would be better off using federated identities from professionally-run Identity Providers.

November 16, 2009
An Experimental Identity Selector for OpenID

OpenID logoThe OpenID community has been talking about the value that an optional active client could bring to OpenID for well over a year. To concretely explore this possibility, as many of you know by now, a team at Microsoft built a prototype multi-protocol identity selector supporting OpenID, starting with CardSpace 2, which I and others demonstrated at the OpenID Summit and the Internet Identity Workshop. We did this to stimulate discussion and engage the community about the value of adding active client support to OpenID. And I’ll say up front that enormous thanks go to Joseph Smarr at Plaxo, the team at JanRain, and Andrew Arnott for building demonstration relying parties that worked with the prototype, which made the demonstrations possible.

While you may have read about it on Kim’s blog and many of you were there in person, I wanted to capture screen shots from the demos to make them available, so those who weren’t there can join the discussion as well. Plus, I’ve posted the presentation that accompanied the demos, rather than reproducing that content here. Now, on to the demo, which closely follows the one actually given at the Summit…

 


Using a selector for the first time

I start by demonstrating the user experience for a first-time selector user at a a selector-enabled OpenID relying party.

 

Plaxo signin
The first screen shot shows a standard Plaxo login screen, but augmented behind the covers to enable it to pass its OpenID authentication request parameters to an active client, if present. I will click on the “Sign in with OpenID” button on the Plaxo signin page, invoking the selector.

In the prototype, selector-enabled relying parties use a variant of the Information Card object tag to communicate their request parameters to the selector. The object tag parameters used on Plaxo’s RP page are:
<object type="application/x-informationCard" id=infoCardObjectTag>
<param name=protocol value="http://specs.openid.net/auth/2.0"/>
<param name=tokenType value="http://specs.openid.net/auth/2.0"/>
<param name=issuer value="Google.com/accounts/o8/id Yahoo.com myOpenID.com"/>
<param name=issuerExclusive value=false/>
<param name=OpenIDAuthParameters value=
"openid.ns:http://specs.openid.net/auth/2.0
openid.return_to:http://www.plaxo.com/openid?actionType=complete
openid.realm:http://*.plaxo.com/
openid.ns.sreg:http://openid.net/extensions/sreg/1.1
openid.sreg.required:email
openid.sreg.optional:fullname,nickname,dob,gender,postcode,country,language,timezone
openid.sreg.policy_url:http://www.plaxo.com/about/privacy_policy
"/>
</object>

 

Plaxo empty selector
Here I’ve clicked on the “Sign in with OpenID” button, invoking the selector. (The “Google” and “Yahoo” buttons would have invoked the selector too.) This shows the first-time selector user experience, where it isn’t yet remembering any OpenIDs for me. The three OPs suggested by Plaxo – Google, Yahoo, and MyOpenID, are shown, as well as the option to type in a different OpenID. I click on the Yahoo suggestion.

 

Plaxo Yahoo first time
Clicking on Plaxo’s Yahoo suggestion resulted in a Yahoo OpenID card being made available for use. Note that, by default, the selector will remember this card for me. (Those of you who know OpenID well are probably thinking “Where did the selector get the Yahoo logo and friendly name string”? For this prototype, they are baked into the selector. Longer term, the right way is for the selector to retrieve these from the OP’s discovery document. The OpenID UX working group is considering defining discovery syntax for doing just that.)

Once I’ve clicked “OK” to select the identity to use, the selector (not the RP) redirects the browser to the OP – in this case, to the Yahoo login page. The selector’s work is done at this point. The remainder of the protocol flow is standard OpenID 2.0.

 

Yahoo Plaxo signin
This is the standard Yahoo OpenID signin page, which the selector redirected the browser to after I choose to use the suggested Yahoo OpenID. I sign into Yahoo.

 

Yahoo Plaxo permission
The signin page is followed by the standard Yahoo permissions page. I click “Agree”.

 

Plaxo signed in
After logging with Yahoo, I’m redirected back to Plaxo. Because I’d previously associated my Yahoo OpenID with my Plaxo account, I’m now logged into Plaxo. My status “Michael is demonstrating an OpenID selector at the OpenID Summit”, which I updated live during the demo at the OpenID Summit, is shown.

 


Selector defaults to the OpenID last used at the site

At this point in the demo, I’ve signed out of Plaxo and returned to the selector-enabled sign-in page. After clicking “Sign in with OpenID” again, the selector reappears.

Plaxo Yahoo second time
This time, the selector has remembered the OpenID I last used at the site and tells me when I last used it there. (This is one of the ways that a selector can help protect people from phishing.) By default, the OpenID last used at a relying party is automatically selected – in this case, Yahoo. I click “OK” to select it, with the rest of the flow again being the standard OpenID 2.0 flow.

 


Experience at a new RP plus a trusted OP experience

Interscope homepage
JanRain selector-enabled several production sites, including interscope.com, uservoice.com, and pibb.com, which use JanRain’s hosted RPX service. This could be done with no impact on users without a selector by using JavaScript to detect whether a selector is present or not, and customizing the page accordingly. The page above is the production Interscope Records page. I click the OpenID button on the right under the “Join The Community” banner.

 

Interscope signon
The OpenID button invokes the RPX “NASCAR” experience. (Arguably, this page could be omitted from the experience if a selector is detected.) I click the OpenID button on the “NASCAR” page.

 

Interscope Yahoo never used here
The selector is invoked by Interscope (really, by RPX) to let me choose an OpenID. My Yahoo OpenID is shown and the “Never used here” tells me that I haven’t used it at this site before. I could choose it by clicking OK or hitting Enter. Instead, I click the “Other OpenIDs” button to explore other options.

 

Interscope other OpenIDs
The “Other OpenIDs” tile shows me the OpenID providers suggested by Interscope – in this case, Flickr, Yahoo, and Google. I click on the Google suggestion.

 

Interscope Google first time
The selector has created a Google OpenID card for me to use. It is marked “Verified” because it (like Yahoo) was on a whitelist in the selector and considered “safe” to use. Of course, in production use, such a whitelist would have to be maintained by a neutral third party or parties and dynamically updated. In the prototype, we hard-coded a few common providers so we could show a user experience that relies on a whitelist of OPs, to start the discussion about that possibility. I hit Enter to use the new Google card at Interscope.

 

Google UniversalMusic signin
Once I chose to use my Google card, the selector redirected me to Google’s signin page, with the actual RP for Interscope being signup.universalmusic.com. I sign into Google.

 

Google UniversalMusic permission
Following signin, Google asks me permission to release information to signup.universalmusic.com. I allow it.

 

Interscope registration
I’m redirected back to Interscope, which asked me to complete a sign-up process by supplying more information via a web form.

 


Selector remembering which OpenID’s you’ve used where

Interscope Google second time
When visiting Interscope again after having signed out, signing in with OpenID shows me that I last used my Google OpenID here. For that reason, it’s selected as the default. I can also see that I haven’t used my Yahoo OpenID here.

 


Trusted versus untrusted OpenIDs

test-id signin
Andrew Arnott created the first selector-enabled relying party site for us, which is shown above. I click “Log in using your OpenID Selector”.

 

test-id Google never used here
Now I have both Yahoo and Google cards, but neither have been used at test-id.org. I notice that I can get more details about my cards, and click “More details” on the Google card.

 

test-id Google more details
“More details” tells me where and when I used the card (signup.universalmusic.com), the discovered OpenID endpoint, and that this OpenID was on the selector’s whitelist. I could now use either of these OpenIDs, but I select “Other OpenIDs” instead.

 

test-id other OpenIDs
The “Other OpenIDs” panel shows me OPs suggested by the site, as well as a dialog box to enter another OpenID. I decide to enter my blog URL self-issued.info, which is also an OpenID.

 

test-id self-issued being entered
Here I’m entering my blog URL self-issued.info into the selector. I then click Verify or OK to have the selector perform discovery on the OpenID to add it as one of my choices.

 

test-id self-issued not verified
Discovery has succeeded, but the OP my blog is delegated to, signon.com, is not on the selector’s whitelist. Because it’s not, a warning shield is shown, rather than the OP logo. I’ll also have to make an explicit decision to trust this OpenID provider before the selector will let me use it. The same would have happened if I chose an OP suggested by the RP if the OP was not on the whitelist. This is another aspect of the selector’s phishing protection. I check the “Continue, I trust this provider” box.

 

test-id self-issued trusted
After checking the “Continue, I trust this provider” box, the warning shield is replaced by either the OP logo, if it can be discovered, or a generic OpenID logo, as in this case. I click OK to use this OpenID.

 

signon test-id signin
The selector follows my delegation link from self-issued.info and redirects me to signon.com. (Ping, are you going to fix the signon.com UX issue above someday?) I sign into signon.com.

 

test-id signed in
Having signed into my OpenID at signon.com, I’m redirected back to the test site, which received an authentication response from the OP. I click “Reset test” to sign out, in preparation for another test.

 


More details

test-id self-issued second time
Upon a second visit to test-id.org, the selector has remembered that I last used the OpenID self-issued.info, which is actually delegated to mbj.signon.com. I click “More details” to learn more about this OpenID.

 

test-id self-issued more details
“More details” tells me where and when I last used the OpenID and that the OpenID has been verified. But unlike my Google OpenID, which was verified via the whitelist, I told the selector to trust this OpenID myself.

 


Delegation to a trusted OP

test-id davidrecordon being entered
At the OpenID Summit, people wanted to see the untrusted user experience again, so I entered an OpenID that I was sure wasn’t on our built-in whitelist – davidrecordon.com. However, verifying the OpenID actually brought me and those in attendance a surprise…

 

test-id davidrecordon verified
Because davidrecordon.com is delegated to myopenid.com, which is on the whitelist, it turns out that the prototype considered davidrecordon.com to be trusted as well. Upon reflection, this is probably the right behavior, but I’d never seen it until giving the demo live. (Great job, Oren!) I tried factoryjoe.com next and got the same result. Finally Will Norris helped me out by saying that willnorris.com isn’t delegated, so we got to see the untrusted user experience again.

 


Conclusion

I’d like to thank Chuck Reeves and Oren Melzer for quickly building a killer prototype and to thank Ariel Gordon and Arun Nanda for helping design it, as well as others, both from Microsoft and other companies, who provided feedback that helped us fine-tune it as we built it. See the presentation for a much more comprehensive list of thank-yous.

I’ll close by saying that in the OpenID v.Next planning meeting at IIW, there was an unopposed consensus that optional active client support should be included as a feature of v.Next. Hopefully our demo, as well as those by others, including Markus Sabadello of Higgins, helped the community decide that this is a good idea by enabling people to concretely experience the benefits that an active client can bring to OpenID. If so, I’d call the experiment a success!

December 30, 2008
PAPE Specification Approved and Ready for Use

OpenID logoAs I just announced on openid.net, OpenID Provider Authentication Policy Extension 1.0 (PAPE) has just been just been approved as an OpenID specification. Deployment of PAPE will go a long way towards mitigating the phishing vulnerabilities of password-based OpenIDs by enabling OpenID Relying Parties to request that OpenID Providers employ phishing-resistant authentication methods when authenticating users and for OpenID Providers to inform Relying Parties whether this (and other) authentication policies were satisfied.

It’s tempting to say that the approval of the specification is the fulfillment of the promise of the OpenID/CardSpace collaboration for phishing-resistant authentication introduced by Bill Gates and Craig Mundie the RSA Security Conference last year, but it’s really just an enabling step. The true value of PAPE will come when it is widely deployed by security-conscious OpenID Relying Parties, and the use of phishing-resistant authentication methods, such as Information Cards and others, is widespread and commonplace. Let the deployments begin!

October 22, 2008
PAPE Specification Entering Public Review Period

OpenID logoThe OpenID Provider Authentication Policy Extension (PAPE) specification enables an OpenID Relying Party to request that the OpenID Provider satisfy a set of policies specified by the RP when the OP logs the user in. And it likewise enables the OP to reply to the RP saying which of the policies it satisfied.

One of these policies lets the RP request that the OP perform phishing-resistant authentication, the need for which has been discussed here and elsewhere. Another capability I’m a fan of is the ability for the RP to “freshness date” the login, requiring that the OP actively authenticate the user if the current authentication was performed longer ago than an RP-specified number of seconds.

The PAPE Working Group just recommended that the OpenID Foundation members approve the current draft (Draft 7) as an OpenID specification. Today starts a 60 day review period required as part of the OpenID specification process, which occurs prior to an approval vote by the members. PAPE is the first new specification to be produced under this process, and I’m pleased as an OpenID board member to report we now have an existence proof that the process works (or more precisely, we will once this specification is approved).

There are already four implementations of this spec in existence and even better, there are public testing endpoints for these implementations where you can kick the tires. You can try the DotNetOpenId and JanRain implementations at these sites:

You should also be able to test the relying parties with signon.com and myopenid.com, which currently implement earlier drafts, since the authentication policy syntax didn’t change.

This spec was a collaborative effort among a number of people. David Recordon wrote the initial drafts last year, with input from the people thanked in Draft 2. Since then, Nat Sakimura was responsible for the generalization of the authentication levels to enable levels other than just those defined by NIST be used. Ben Laurie was an ardent and practical security advocate (as always). Allen Tom was a proponent of the strong “level 0” description. Andrew Arnott of the DotNetOpenId project shared his experiences building an independent implementation with the working group, helping improve the specification. And John Bradley was a never-ending source of common sense, although he would deny it to your face if asked.

July 4, 2008
Digital Identity Podcast for MySuccessGateway

MicrophoneKim Cameron and I recorded a podcast on digital identity for MySuccessGateway this week at the invitation of Jim Peake of SpeechRep Consulting. Jim was a gracious, informed, and enthusiastic host during our conversation, which covered a wide range of digital identity topics including identity theft, shared secrets, privacy, Information Cards and the Information Card Foundation, the value of verified claims, business models for identity providers, password fatigue, defeating phishing attacks, OpenID, why interoperability is essential and the interoperability testing the industry is doing together to make it a reality, some of the identity products that are shipping and forthcoming, and the Laws of Identity. He even asked us how we felt about Bill Gates’ retirement, as a kicker.

If that sounds interesting to you, give it a listen

June 24, 2008
A Personal Perspective on the Information Card Foundation Launch

Information Card Foundation banner

In May 2005, when I wrote the whitepaper “Microsoft’s Vision for an Identity Metasystem”, these sentences were aspirational:

Microsoft’s implementation will be fully interoperable via WS-* protocols with other identity selector implementations, with other relying party implementations, and with other identity provider implementations.

Non-Microsoft applications will have the same ability to use "InfoCard" to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

Now they are present-day reality.

This didn’t happen overnight and it wasn’t easy. Indeed, despite it being hard, the identity industry saw it as vitally important, and made it happen through concerted, cooperative effort. Key steps along the way included the Laws of Identity, the Berkman Center Identity Workshops in 2005 and 2006, the Internet Identity Workshops, the establishment of OSIS, the formation of the Higgins, Bandit, OpenSSO, xmldap, and Pamela projects, publication of the Identity Selector Interoperability Profile, the Open Specification Promise, the OSIS user-centric identity interops (I1 rehearsal, I1, I2, I3, and the current I4), the OpenID anti-phishing collaboration, the Information Card icon, and of course numerous software releases by individuals and companies for all major development platforms, including releases by Sun, CA, and IBM.

Of course, despite all the groundwork that’s been laid and the cooperation that’s been established, the fun is really just beginning. What most excites me about the group of companies that have come together around Information Cards is that many of them are potential deployers of Information Cards, rather than just being producers of the underlying software.

The Internet is still missing a much-needed ubiquitous identity layer. The good news is that the broad industry collaboration that has emerged around Information Cards and the visual Information Card metaphor is a key enabler for building it, together in partnership with other key technologies and organizations.

The members of the Information Card Foundation (and many others also working with us) share this vision from the conclusion of the whitepaper:

We believe that many of the dangers, complications, annoyances, and uncertainties of today’s online experiences can be a thing of the past. Widespread deployment of the identity metasystem has the potential to solve many of these problems, benefiting everyone and accelerating the long-term growth of connectivity by making the online world safer, more trustworthy, and easier to use.

In that spirit, please join me in welcoming all of these companies and individuals to the Information Card Foundation: founding corporate board members Equifax, Google, Microsoft, Novell, Oracle, and PayPal; founding individual board members Kim Cameron, Pamela Dingle, Patrick Harding, Andrew Hodgkinson, Ben Laurie, Axel Nennker, Drummond Reed, Mary Ruddy, and Paul Trevithick; launch members Arcot Systems, Aristotle, A.T.E. Software, BackgroundChecks.com, CORISECIO, FuGen Solutions, Fun Communications, Gemalto, IDology, IPcommerce, ooTao, Parity Communications, Ping Identity, Privo, Wave Systems, and WSO2; associate members Fraunhofer Institute and Liberty Alliance; individual members Daniel Bartholomew and Sid Sidner.

June 23, 2008
Identity Choice at HealthVault

OpenID logoSean Nolan, chief architect of Microsoft’s HealthVault service, posted an article about giving their users choice for the identities they use to access their information. He announced that in addition to accepting LiveIDs, HealthVault is about to start accepting OpenIDs from two OpenID Providers and is also building native Information Card support. As Sean wrote:

As we’ve always said, HealthVault is about consumer control — empowering individuals with tools that let them choose how to share and safeguard their personal health information. OpenID support is a natural fit for this approach, because it allows users to choose the “locksmith” that they are most comfortable with.

You can certainly expect to see more such options in the future. For example, we are in the process of building in native support for Information Cards, which provide some unique advantages, in particular around foiling phishing attempts.

Talking about OpenID, Sean also wrote:

As we learn more, and as OpenID continues to mature, we fully expect to broaden the set of providers that work with HealthVault. We believe that a critical part of that expansion is the formalization and adoption of PAPE, which gives relying parties a richer set of tools to determine if they are comfortable with the policies of an identity provider.

Please join me in congratulating the HealthVault team on being the first Microsoft service to employ OpenID and for their commitment to providing their users convenient, secure access to their healthcare data.

May 26, 2008
Even Phishers Have Their Problems

While gone phishing, I discovered that the use of JavaScript puts one barrier up that phishers have to overcome to impersonate a legitimate site. In a characteristically hilarious post, Paul Madsen points out that, besides having to overcome active defenses like Sxipper (“Down girl!”), phishers may also inadvertently present pages localized for their locale, rather than the victim’s.

Intrepid identity adventurer though Paul may be, this stopped him dead in his tracks:

Deutsche Blogger login

Of course, maybe Paul’s German was better than he thought, as the page was urging him to “Gehen Sie auf Nummer sicher! Schützen Sie sich von Phishing und Identitätsdiebstahl.” – “Go safe! Protect yourself from phishing and identity theft.” :-)

May 26, 2008
Gone Phishing

Fun Communications’ site idtheft.fun.de lets you mount your very own man-in-the-middle based phishing attack against the OpenID provider of your choosing. Rather than redirecting you to the OpenID provider you specify, it instead redirects you to a page impersonating the OpenID provider, created using content scraped from the real site behind the scenes.

This is the same kind of attack shown in Kim’s phishing video. idtheft.fun.de lets you have the fun of doing it yourself!

I tried it myself with several OpenID providers I use. Predictably, I was typically able to “steal” the passwords for OpenIDs when logging into them with passwords and hijack the resulting logged-in sessions. “Protecting” an account with a one-time-password (OTP) device did nothing to stop this; my “attack” still succeeded in hijacking the session established using a password in combination with an OTP value.

Two things did defeat these attacks. Because Information Cards generate site-specific sign-in information and the attacker’s site is different than the authentic site, even when I was “tricked” into submitting an Information Card to the imposter site, it didn’t give the imposter the ability to log into the real site. No shared secret was present to steal and no session was established to hijack.

The other thing that defeated this specific attack was the use of JavaScript in the sign-in process by the OpenID provider. While a slightly more sophisticated attack could almost certainly get past this obstacle, idtheft.fun.de apparently doesn’t correctly mimic JavaScript site features like “Sign In” buttons invoking an onclick method.

This ability to both phish passwords and hijack the resulting logged-in sessions is exactly why I and others are working on finishing the OpenID Provider Authentication Policy Extension (PAPE) extension. As I wrote when the first draft was published, PAPE enables “OpenID relying parties to request that a phishing-resistant authentication method be used by the OpenID provider and for providers to inform relying parties whether a phishing-resistant authentication method, such as Windows CardSpace, was used.” It’s time for PAPE to become an OpenID standard.


What follows are screen shots from a successful phishing attack and a thwarted one – both against the same OP. The difference is whether passwords or Information Cards were used to log in.

Figure 1: idtheft start

Figure 1: About to mount my attack against my OpenID at myopenid.com. I’ve typed the URL of my OpenID into the relying party.

Figure 2: idtheft signin

Figure 2: Next, I’m logging in with a password. An observant user could notice several things wrong: the address bar shows the imposter’s URL, the imposter’s URL is present in the “You must sign in to authenticate to …” message, and the “Your Personal Icon” space is blank. Unfortunately, there is strong evidence that users are not observant.

Figure 3: idtheft allow

Figure 3: Phishing already accomplished. Same cues are present that something’s amiss. Of course, a more sophisticated attack could replace the imposter’s URL in the page with the “real one” in both of these screens, eliminating the most obvious cue. I scroll down and click “Allow Once”.

Figure 4: idtheft accomplished

Figure 4: Result after being redirected back to the “relying party”. Yes, that was my real password.

Next, I tried to attack my account again but was surprised that I wasn’t asked to log in this time. Of course – the attacker’s session was already logged in! So I signed out as the man-in-the-middle (that was weird), enabling me to try again.

My next steps looked just like Figures 1 and 2, except instead of typing a password I clicked the purple Information Card button. This brought me to:

Figure 5: idtheft cardspace

Figure 5: CardSpace informs me that I’ve never sent a card to this site before. An observant user would realize that they don’t normally see this screen and might decline. But then, we’ve already discussed how observant users aren’t. I click “Yes”, choose the card I normally use to log into myopenid.com, and send it.

Figure 6: idtheft prevented

Figure 6: Phishing prevented. “Error processing Information Card token” isn’t the most informative error message I’ve ever seen but behind it is great news: the phishing attack failed because the token constructed for the imposter site wasn’t usable at the real site.

And thanks to idtheft.fun.de, you can try this at home!

May 26, 2008
Fun Communication’s Fun Identity Innovations

Fun Communications logoJohannes Feulner of Fun Communications recently showed me three different identity sites they’ve created, each fun and valuable in its own way. The first, www.webcard-loyalty.com, lets companies create online loyalty cards for their customers. These loyalty Information Cards enable merchants to offer bonuses and discounts when the cards are used, similarly to how physical loyalty cards such as frequent flyer cards and frequent shopper cards are used to provide these benefits in the offline world. You can read more about “virtual loyalty cards” and about the innovation prize they won.

The second, openidbycard.com, dynamically creates a site-specific OpenID to use at an OpenID relying party from any Information Card offering the privatepersonalidentifier (PPID) claim. Type “openidbycard.com” as your OpenID identifier into any OpenID login form and an OpenID will be created for the site based on the site identity and the PPID returned by the card. While I understand value of using public identifiers (such as self-issued.info) in some contexts, it’s great to also have the choice of using unidirectional identifiers at OpenID sites.

Finally, idtheft.fun.de demonstrates the ability of attackers to mount man-in-the-middle attacks against OpenID sites (and lets you try it yourself!). The site phishes OpenID passwords and other information sent through the browser, all via web pages that look authentic, but that are actually under control of the attacker. This will be the subject of my next post.

April 1, 2008
User-Centric Identity Interop at RSA in San Francisco

33 Companies…
24 Projects…
57 Participants working together to build an interoperable user-centric identity layer for the Internet!

Come join us!

Tuesday and Wednesday, April 8 and 9 at RSA 2008, Moscone Center, San Francisco, California
Location: Mezzanine Level Room 220
Interactive Working Sessions: Tuesday and Wednesday, 11am – 4pm
Demonstrations: Tuesday and Wednesday, 4pm – 6pm
Reception: Wednesday, 4pm – 6pm

Logos of RSA 2008 Interop Participants

February 7, 2008
Microsoft Joins the OpenID Foundation and its Board of Directors

OpenID logoToday the OpenID Foundation announced that five leading technology companies, Google, IBM, Microsoft, VeriSign, and Yahoo! have joined the OpenID board of directors as its first corporate board members. This news comes a year and a day after the JanRain/Sxip Identity/Microsoft/VeriSign OpenID/CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference.

How are these events related, you might ask? As I see it, they’re both great examples of the industry working together to solve the digital identity problems that all Internet users presently face – in these cases, both in the context of OpenID.

A lot’s happened over that year-and-a-day that’s worth celebrating:

From a personal perspective, I’ve enjoyed working with colleagues from numerous companies (including from my own!) to help get us to today’s announcement, as well as working to bring safer, easier-to-user login and account creation to OpenIDs via Information Cards. Thus, I’m both pleased and honored to now be representing Microsoft on the OpenID Foundation board of directors.

Of course, today’s announcement is really only the end of the beginning. The real fun and value is still ahead of us, in the work we’ll do together. The draft PAPE specification needs to be completed. We need to drive relying party adoption of phishing-resistant authentication. And talk of an OpenID 3.0 that’s both easier and safer to use is already percolating on the mailing lists.

The Internet is still missing a much-needed ubiquitous identity layer. The good news is that the broad industry collaboration that has emerged around OpenID is a key enabler for building it together!

December 22, 2007
Phishing Protection for the Enterprise

Enterprise Phishing ProtectionI was surprised during the recent blogosphere conversation on user-centric identity in the Enterprise, that no one referenced Sxip’s contemporaneous intelligently-written 2-page piece on how the use of Information Cards can help protect enterprise login credentials from being phished. Using Information Cards to enable safer remote access to hosted enterprise applications makes business sense. This seems to me like a perfect example of what Pam wrote: “I would like to see Enterprises adopt technologies such as the Identity Metasystem for no other reason than because it helps their business to succeed.”

Dick’s introduction to the security bulletin also references a number of recent press articles on phishing attacks against the enterprise that are well worth reading. I’m with Pam: user-centric identity technologies will be adopted in the enterprise exactly when they’re perceived as delivering real business value. This is such a case.

December 19, 2007
I-names without Passwords at LinkSafe

I’m pleased to report that ooTao and LinkSafe have recently collaborated to enable you to create and use i-names with Information Cards rather than passwords. They’ve achieved for LinkSafe.name what JanRain did for MyOpenID.com. Below is a screen shot of me signing up for an i-name using an Information Card, rather than a password. Now when you see someone signed in to a site with the OpenID =me, you’ll know who it actually is!

LinkSafe.name i-name signup with Information Card

December 2, 2007
Look ma! No passwords!

As Vittorio excitedly pointed out, you never have to enter a password to create or use an OpenID at MyOpenID.com. Kim’s excited about this too. So am I. When I wrote:

The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.

I should have expanded upon my point “fantastic job integrating account sign-up” to explicitly call out that no passwords are needed. Notice the Information Card button on the sign-up page below. Thanks Vittorio and Kim, for sharing your excitement about this. I’m hoping that as other sites integrate Information Card sign-in to their user experience that they’ll also follow this example (and the guidance in the deployment guide) and enable password-less sign-up with Information Cards.

MyOpenID.com signup with Information Card

Related to this is JanRain’s earlier announcement that they are including PAPE support in their widely-used OpenID relying party libraries. As Kevin Fox wrote:

Just a note to let everyone know that we are developing and will release relying party libraries supporting PAPE once the specification is finalized.
We have deployed an example relying party available here:
openidenabled.com/python-openid/trunk/examples/consumer/
The example fully supports OpenID 2.0 draft 12, and can request phishing-resistant authentication using PAPE. Feel free to use it for testing.
PAPE allows sites that use OpenID 2.0 authentication to get information about the way that the user authenticated to the provider. This is an important step on the way to getting the convenience needed of OpenID authentication for higher-valued transactions. It’s trivial to implement and will be included in JanRain’s OpenID 2.0 libraries as well as Sxip’s libraries.

Gary Krall also added that:

Verisign will also be releasing an update to the JOID library which we use on the PiP for as you may know we have added PAPE support to the PiP.

And I’ll add that MyOpenID.com and SignOn.com both also support PAPE on their OpenID providers.

Why is this exciting? Because it means that without use of without any use of passwords, people can create and use OpenIDs with their Information Cards. And that sites accepting OpenIDs can ask for phishing-resistant authentication when you sign in – which these OpenIDs will do for you. All more great steps towards building a convenient, secure, ubiquitous identity layer for the Internet!

October 24, 2007
User-Centric Identity Interop at Catalyst in Barcelona

Logos of Barcelona Interop Participants 2007

Last night OSIS and the Burton Group held the third in a series of user-centric identity Interop events where companies and projects building user-centric identity software components came together and tested the interoperation of their software together. Following on the Interops at IIW in May and Catalyst in June, the participants continued their joint work of ensuring that the identity software we’re all building works great together.

This Interop had a broader scope along several dimensions than the previous ones:

An excerpt from Bob Blakley’s insightful-as-always commentary on the Interop is:

The participants have posted their results on the wiki, and a few words are in order about these results. The first thing you’ll notice is that there are a significant number of “failure” and “issue” results. This is very good news for two reasons.

The first reason it’s good news is that it means enough new test cases were designed for this interop to uncover new problems. What you don’t see in the matrix is that when testing began, there were even more failures – which means that a lot of the new issues identified during the exercise have already been fixed.

The second reason the “failure” and “issue” results are good news is that they’re outnumbered by the successes. When you consider that the things tested in Barcelona were all identified as problems at the previous interop, you’ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.

Be sure to read his full post for more details on what the participants accomplished together. And of course, this isn’t the end of the story. An even wider and deeper Interop event is planned for the RSA Conference in April 2008. Great progress on building the Internet identity layer together!

October 18, 2007
MyOpenID adds Information Card Support

JanRain logoKevin Fox just announced that JanRain has added Information Card support to MyOpenID.com. As he wrote:

The JanRain OpenID team is pleased to announce Information Card support has been added to MyOpenID.com.

What is an Information Card?

What can I do with it? With a self-issued Information Card you can sign-in to MyOpenID, as well as sign-up and recover your account, without ever having to enter your password. Anywhere on MyOpenID that you can enter a password will now allow you to use an Information Card instead. With the addition of Information Card support MyOpenID is able to offer another solid option for people wanting to protect their OpenID account from phishing attacks and remember fewer passwords.

We were able to work with Microsoft’s Mike Jones and Kim Cameron who have both been long time proponents of OpenID + Information Card support.

As noted by Kim Cameron “Cardspace is used at the identity provider to keep credentials from being stolen. So the best aspects of OpenID are retained.” While one of the less desirable aspects (confusing user experience) has been improved for someone using an Information Card to login to their OpenID provider.

Support for Information Cards has been growing as more software projects implement the technology. It is important to note that this technology is being supported by many other organizations besides Microsoft. Information Card support is available for Windows platforms (Vista / XP) as well as Mac OS X and Linux.

The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.

There’s another kind of integration they also did that makes this even more impressive in my mind: connecting their new Information Card support with their existing support for the draft OpenID phishing-resistant authentication specification. This is another significant step in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year. Because of this work, this sequence is now possible:

  1. A person goes to an OpenID relying party and uses an OpenID from MyOpenID.com.
  2. The OpenID relying party requests that MyOpenID.com use a phishing-resistant authentication method to sign the user in.
  3. The person signs into his MyOpenID.com OpenID with an Information Card.
  4. MyOpenID.com informs the relying party that the user utilized a phishing-resistant authentication method.

This means that MyOpenID users will be able to get both the convenience and anti-phishing benefits of Information Cards at OpenID-enabled sites they visit and those sites can have higher confidence that the user is in control of the OpenID used at the site. That’s truly useful identity convergence if you ask me!

– Mike (http://self-issued.myopenid.com/)
August 26, 2007
Information Cards for OpenIDs

Sxip Identity just finished a draft specification that enables a really useful form of convergence between OpenIDs and Information Cards: presenting your OpenID as an Information Card you select rather than as a string you type. Johnny Bufu’s OpenID general mailing list note introduces this specification for community review.

This combination has several advantages over standard OpenID usage. First, there’s no OpenID string to type when you use your OpenID, which should make OpenIDs easier for more people to use. Second, this is a phishing-resistant authentication method. Finally, it lets you recognize and choose your OpenID visually, based on the card graphics supplied by the OpenID provider.

Sxip also backed this specification by a sample implementation, which you can check out at https://openidcards.sxip.com/. Now for some more details….

Here’s how it works: In this model, the OpenID relying party asks for an OpenID Information Card using an object tag on the page rather than having the user type the OpenID as a string (while probably also giving the user the option to instead type in the string for backwards compatibility). The user’s Identity Selector then lets the user choose which OpenID card to send to the site. The card transmits the actual OpenID string to the site as a claim. From that point on, standard OpenID protocol interactions ensue.

For instance, the sample relying party page asks you to “Login with an OpenID InfoCard” and requests the card using this evocative graphic:

OpenID InfoCard

Upon clicking the graphic, my identity selector is invoked, which shows me that I can use this OpenID Information Card at the site (which I’d previously obtained here):

Sxip OpenID InfoCard

After that, the sample performed a standard OpenID attribute exchange and the relying party greeted me with:

Welcome! You have logged in using your https://openidcards.sxip.com/i/mbj OpenID identifier.

Phone: (omitted)
Country: USA
Email: mbj@microsoft.com
City: Redmond
Address: One Microsoft Way, Building 40/5138
LastName: Jones
FirstName: Mike

Behind the scenes, the relying party had received this OpenID assertion:

<openid:OpenIDToken xmlns:openid="http://specs.openid.net/auth/2.0">openid.ns:http://specs.openid.net/auth/2.0
openid.op_endpoint:https://openidcards.sxip.com/op/
openid.claimed_id:https://openidcards.sxip.com/i/mbj
openid.response_nonce:2007-08-26T20:55:34Z0
openid.mode:id_res
openid.identity:https://openidcards.sxip.com/i/mbj
openid.return_to:https://openidcards.sxip.com/demorp/
openid.assoc_handle:f27d249fc4108198
openid.signed:op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle
openid.sig:gKKpDjEbgByJo48Q800Jq4gCJng=
openid.ns.ext1:http://openid.net/srv/ax/1.0-draft4
openid.ext1.mode:fetch_response
openid.ext1.type.attr1:http://axschema.org/contact/phone/default
openid.ext1.value.attr1:(omitted)
openid.ext1.type.attr2:http://axschema.org/contact/country/home
openid.ext1.value.attr2:USA
openid.ext1.type.attr3:http://axschema.org/contact/email
openid.ext1.value.attr3:mbj@microsoft.com
openid.ext1.type.attr4:http://axschema.org/contact/city/home
openid.ext1.value.attr4:Redmond
openid.ext1.type.attr5:http://axschema.org/contact/postalAddress/home
openid.ext1.value.attr5:One Microsoft Way, Building 40/5138
openid.ext1.type.attr6:http://axschema.org/namePerson/last
openid.ext1.value.attr6:Jones
openid.ext1.type.attr7:http://axschema.org/namePerson/first
openid.ext1.value.attr7:Mike
</openid:OpenIDToken>

One final technical note that will be of interest to some of you: OpenID Information Cards do not use SAML tokens. They use one of two variants of openid:OpenIDToken tokens (depending upon whether the OpenID relying party uses OpenID 1.1 or 2.0 authentication).

Go get yourself an OpenID Information Card and give it a spin! Read and comment on the spec. Or even better yet, implement it and tell us about your experience!

July 27, 2007
Information Cards at OpenID Providers

PIP InfoCardsThis week VeriSign upgraded their Personal Identity Provider (PIP) to support Information Cards. As David Recordon wrote at VeriSign’s official “Infrablog”:

Last Saturday, we completed the upgrade of our Personal Identity Provider. All accounts have been automatically upgraded and the URL is the same at http://pip.verisignlabs.com. We definitely encourage everyone to come try it out as we believe it is the best OpenID Provider in existence! Not only does it have all of the features from the PIP we launched last May, but adds support for OpenID 2.0, the ability to manage multiple identities within one PIP account, integration with strong authentication via our VeriSign Identity Protection network, Information Card support as one way to help protect against phishing attacks, and our SeatBelt Firefox add-on which works with a variety of OpenID Providers.

PIP supports Information Cards in two ways:

  • Logging into your PIP account: You can use a managed Information Card to log into your PIP account, providing a phishing-resistant alternative to logging in with a username and password typed into the browser.
  • Using your PIP Identities at other sites: PIP issues managed Information Cards for each of your PIP identities, which you can use to sign into sites using Information Cards for login and/or account creation. (And of course, these same identities are also OpenIDs as well.)

Images of my PIP cards for these two use cases are shown at the top of this post. I can now use my PIP account card to sign into my PIP account and my PIP identity card to sign into other sites. PIP is doubly cool because I believe it’s also the first general-purpose identity provider to be secured by an Extended Validation Certificate (see the green color of the IE7 address bar?). Great progress!

SignOn.com LogoThis follows on last month’s launch of Ping Identity’s SignOn.com identity provider. SignOn.com lets you log into your OpenID account using a self-issued Information Card — a convenient, password-free, and phishing-resistant authentication mechanism.

Both are fantastic steps towards our shared goal of building a convenient, secure, ubiquitous identity layer for the Internet. Expect to see lots more developments like this soon!

Yours truly,
mbj.pip.verisignlabs.com and mbj.signon.com

June 23, 2007
Phishing-Resistant Authentication Specification Ready

David Recordon just posted a simple draft OpenID specification enabling OpenID relying parties to request that a phishing-resistant authentication method be used by the OpenID provider and for providers to inform relying parties whether a phishing-resistant authentication method, such as Windows CardSpace, was used. This is a major step forward in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year.

In his post “Bringing Useful Scalable Security to OpenIDDavid wrote:

The integration cost of OpenID as a Relying Party is extremely low, the technology is free and as Brian Ellin and I showed at Web 2.0 Expo the time commitment is also low due to a lot of great Open Source code out there which takes care of the heavy lifting. So now the RP has successfully integrated OpenID and removed the need for new users to create yet another password for their site, though they no longer have the control over the strength of a user’s authentication process. The RP may be a simple Web 2.0 site and not care beyond that the user has a password, it may store marginally sensitive information and want to make sure that the Provider did something to help protect the user from common phishing attacks, or maybe it’s a site which has truly sensitive information and wants to make sure that a second-factor device, such as a VIP token, was used.

With the OpenID Provider Authentication Policy Extension that I just published, this is now possible. This extension to OpenID 1.1 and 2.0 allows Relying Parties to express preferences around the authentication, such as “use technology which is phishing resistant” (stemming from the collaboration announcement at the RSA conference earlier in the year), for the Provider to inform the user of the request, guide them through the authentication process, and then inform the Relying Party what happened. By taking advantage of existing specifications from the likes of the National Institute of Standards and Technology (NIST), Providers can also convey information as to the strength of a password or combination of a password and digital certificate or hardware device used. While the high-end of the specification may be beyond the uses of OpenID today, it certainly fulfills the scalable security vision that we have. Through this specification not only can I now strongly protect my OpenID identity, but let others know that I’m doing so and truly take advantage of a reduction in credentials needed when browsing the web.

I can’t wait to use the implementations that are sure to follow shortly!