Archive for the 'Phishing Resistance' Category

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!

« Prev