Phishing – Kim Cameron's Identity Weblog

Six new authentication methods for Identityblog

Back in March 2006, when Information Cards were unknown and untested, it became obvious that the best way for me to understand the issues would be to put Information Cards onto Identityblog.

I wrote the code in PHP, and a few people started trying out Information Cards. Since I was being killed by spam at the time, I decided to try an experiment: make it mandatory to use an Information Card to leave a comment. It was worth a try. More people might check out InfoCards. And presto, my spam problems would go away.

So on March 18th 2006 I posted More hardy pioneers try out InfoCard, showing the first few people to give it all a whirl.

At first I thought my draconian “InfoCard-Only” approach would get a lot of peoples’ hackles up and only last a few weeks. But over time more and more people seemed to be subscribing – probably because Identityblog was one of the few sites that actually used InfoCards in production. And I never had spam again.

How many people joined using InfoCards? Today I looked at my user list (see the screenshot below with PII fuzzed out). The answer: 2958 people successfully subscribed and passed email verification. There were then over 23,000 successful audited logins. Not very many for a commercial site, but not bad for a technical blog.

Of course, as we all know, the powers at the large commercial sites have preferred the “NASCAR” approach of presenting a bunch of different buttons that redirect the user to, uh, something-or-other-that-can-be-phished, ahem, in spite of the privacy and security problems. This part of the conversation will go on for some time, since these problems will become progressively more widespread as NASCAR gains popularity and the criminally inclined tune in to its potential as a gold mine… But that discussion is for another day.

Meanwhile, I want to get my hands dirty and understand all the implications of the NASCAR-style approach. So recently I subscribed to a nifty janrain service that offers a whole array of login methods. I then integrated their stuff into Identityblog. I promise, Scout's Honor, not to do man-in-the-middle-attacks or scrape your credentials, even though I probably could if I were so inclined.

From now on, when you need to authenticate at Identityblog, you will see a NASCAR-style login symbol. See, for example, the LOG IN option at the top of this page.

If you are not logged in and you want to leave a comment you will see :

Click on the string of icons and you get something like this:

Because many people continue to use my site to try out Information Cards, I've supplemented the janrain widget experience with the Pamelaware Information Card Option (it was pretty easy to make them coexist, and it leaves me with at least one unphishable alternative). This will also benefit people who don't like the idea of linking their identifiers all over the web. I expect it will help researchers and students too.

One warning: Janrain's otherwise polished implementation doesn't work properly with Internet Explorer – it leaves a spurious “Cross Domain Receiver Page” lurking on your desktop. [Update – this was apparently my problem: see here] Once I figure out how to contact them (not evident), I'll ask janrain if and when they're going to fix this. Anyway, the system works – just a bit messy because you have to manually close the stranded empty page. The problem doesn't appear in Firefox.

It has already been a riot looking into the new technology and working through the implications. I'll talk about this as we go forward.

My Twitterank is 101.54

In case you need mind-stretching with regard to credulity, try out this piece from Sprout Marketing:

Madness erupted on Twitter last night, as the latest cool “app,” Twitterank, was suddenly accused of being a simple password swiping scheme. Over the past 48 hours, thousands of people were Tweeting the same message:

my Twitterank is 101.54!

Each one of those thousands of users freely gave out their username and password to the site. In exchange, the site uses some complicated algorithm (or not, maybe it's entirely random) and out pops a rating.

Then around 3 p.m. or so, Mountain Time, PANIC broke out.

This is how e-riots start...

Within minutes, similar messages were everywhere. This is the online equivalent of an angry, confused mob [FOLLOW the incredible link – Kim] . ZDnet jumped in, along with dozens of other legitimate news sources.

News is breaking out this morning that it really isn't a scam at all. Regardless, I think there are a couple lessons here.

1. Twitter people need to be a lot more careful about their passwords. A lot of them use the same passwords across multiple sites. If the Twitterank person wanted, he could be posting to your blog while ordering expensive popcorn with your credit card.

2. How trustworthy is your brand? Do people have confidence in coming to your site that if they share personal information, it'll be protected? It took eBay and Amazon years to get to this point; they were the pioneers. There are tons of sites that do e-commerce now, thanks to Amazon.

Then you look at the Twitterank site; does it instill confidence? Kind of reminds me of an old Yahoo! Geocities page. Sure, he did it late one night for kicks, and he SAYS he won't take your password…

Apparently this was good enough for tons of people. But I bet they're rethinking that today.

The average person has no way of evaluating the extent to which their passwords are in danger, especially when presented with two related sites that perform redirection or ask for entry of passwords.

The only safe solution for the broad spectrum of computer users is one in which they cannot give away their secrets. In other words: Information Cards (the advantage being they don't necessarily require hardware) or Smart Cards. Can there be a better teacher than reality?

[Via Vu – Thanks]

Crypto flaw + bad practices = need for governance

Speaking of issues of governance, the Register just brought us this report on a recent “archeological investigation” by Ben Laurie and Richard Clayton that revealed how a Linux security flaw left a number of OpenID sites vulnerable to attack:

“Slipshod cryptographic housekeeping left some OpenID services far less secure than they ought to be.

“OpenID is a shared identity service that enables users to eliminate the need for punters to create separate IDs and logins for websites that support the service. A growing number of around 9,000 websites support the decentralised service, which offers a a URL-based system for single sign-on.

“Security researchers discovered the websites run by three OpenID providers – including Sun Microsystems – used SSL certificates with weak crypto keys. Instead of being generated from billions of possibilities, the keys came from a a set of just 32,768 options, due to a flaw in the random number generation routines used by Debian. The bug, which has been dormant on systems for 18 months, was discovered and corrected back in May.

“Keys generated by cryptographically flawed systems still needed to be replaced even after the software was upgraded. But recent research by Ben Laurie of Google reveals that 1.5 per cent of certificates he looked at contained weak keys. Three OpenID providers (openid.sun.com, xopenid.net and openid.net.nz) were among the guilty parties.

“To exploit the vulnerability, malicious hackers would need to trick surfers into visiting a site impersonating a pukka OpenID provider. But faking digital certificate alone wouldn't do the trick without first misdirecting surfers to these bogus sites. Dan Kaminsky's recent discovery of a DNS cache poisoning flaw made it far more plausible to construct an attack that sent surfers the wrong away around the net's address lookup system, potentially to a bogus Open site posing as the real deal.

“The security flaw meant that even cautious users who check SSL certificates were at risk of handing over their OpenID credentials as part of a phishing attack. Such an attack would take a lot of effort to pull off and would only yield OpenID login credentials, which aren't especially useful for hackers and are difficult to monetise.

“Going after online banking credentials via a site that makes no attempt to offer up fake SSL certificates is a far more reliable moneyspinner, a factor that leads noted security researcher Richard Clayton to describe the attack as the “modern equivalent of a small earthquake in Chile”.

“Sun has responded to the issue by generating a new secure key, which reduces the scope for mischief but still leaves potential problems from the old key.

“More thoughts on the cryptographically interesting – though not especially life-threatening – flaw can be found in Clayton's posting on Cambridge University's Light the Blue Touchpaper blog here. A security advisory by Laurie and Clayton explaining the issue in greater depth can be found here.”

I tip my hat to Ben and Richard for doing what I think of as “system archeology” – looking into the systems people actually leave behind them, as opposed to the ones they think they have built. We need a lot more of this. In fact, we need to have full time archeologists rigorously exploring what is being deployed.

This said, I have to question the surprisingly opportunistic title of Richard's piece: An insecurity in OpenID, not many dead.

Let's get real. None of what went wrong here was in any way specific to OpenID. The weakness would have struck any application that relied on crypto and was built on Debian Linux and operated in the same way. This includes SSL, which for some reason doesn't get singled out. And it applies to SAML, WS-Trust and PKI (e.g. any of the security-based identity protocols). Is OpenID a convenient straw man?

In fact there were really two culprits. First, the crypto flaw itself, a problem in Linux. Second, the fact that although the flaw had been fixed, new keys and certificates had not been obtained by a number of the operators.

So we are brought right back to the issue of governance, and in all fairness, Richard makes that point too. Given the improper operating practices, and the fact that OpenID imples no contractual agreement, how would anyone have been able to sort out liability if the flaw had resulted in a serious breach?

Clearly, timely patching of one's operating system needs to be one of the host of requirements placed on any identity provider. A system of governance would make this explicit, and provide a framework for assigning liability should the requirement not be met. I really think we need to move forward on a broadly inclusive governance conversation.

And finally, just so no one thinks I have gone out of character, let's all note that any user who employed an Information Card to authenticate to the OpenID provider would NOT have had her credentials stolen, in spite of the vulnerability Ben and Richard have documented.

New York Times on OpenID and Information Cards

Randall Stross has a piece in the NYT that hits the jackpot in explaining to non-technical readers what's wrong with passwords and how Information Cards help:

“I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them.

“That would be the case even if we had done a better job of listening to instructions. Surveys show that we’ve remained stubbornly fond of perennial favorites like “password,” “123456” and “LetMeIn.” The underlying problem, however, isn’t their simplicity. It’s the log-on procedure itself, in which we land on a Web page, which may or may not be what it says it is, and type in a string of characters to authenticate our identity (or have our password manager insert the expected string on our behalf).

“This procedure — which now seems perfectly natural because we’ve been trained to repeat it so much — is a bad idea, one that no security expert whom I reached would defend.”

“The solution urged by the experts is to abandon passwords — and to move to a fundamentally different model, one in which humans play little or no part in logging on. Instead, machines have a cryptographically encoded conversation to establish both parties’ authenticity, using digital keys that we, as users, have no need to see.

“In short, we need a log-on system that relies on cryptography, not mnemonics.

“As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code…”

Randall's piece also drills into OpenID. Summarizing, he sees it as a password-based system, and therefore a diversion from what's really important:

“OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site. Nevertheless, every few months another brand-name company announces that it has become the newest OpenID signatory. Representatives of Google, I.B.M., Microsoft and Yahoo are on OpenID’s guiding board of corporations. Last month, when MySpace announced that it would support the standard, the nonprofit foundation OpenID.net boasted that the number of “OpenID enabled users” had passed 500 million and that “it’s clear the momentum is only just starting to pick up.”

“Support for OpenID is conspicuously limited, however. Each of the big powers supposedly backing OpenID is glad to create an OpenID identity for visitors, which can be used at its site, but it isn’t willing to rely upon the OpenID credentials issued by others. You can’t use Microsoft-issued OpenID at Yahoo, nor Yahoo’s at Microsoft.

“Why not? Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised. They do not want to take on the liability for mischief originating at someone else’s site.

Randall is right that when people use passwords to authenticate to their OpenID provider, the system is vulnerable to many phishing attacks. But there's an important point to be made: these problems are caused by their use of passwords, not by their use of OpenID.

When people authenticate to OpenID in a reliable way – for example, by using Information Cards – the phishing attacks are no longer possible, as I explain in this video. At that point, it becomes a safe and convenient way to use a public personna.

The question of whether and when large sites will accept the OpenIDs issued by other large sites is a more complicated one. I discussed a number of the issues here. The problem is that for many applications, there needs to be a layer of governance on top of the identity basic technology. What happens when something goes wrong? Are there reliability and quality of service guarantees? If informaiton is leaked, who is responsible? How is fiscal liability established? And by the way, we need to figure this out in order to use any federation technology, whether OpenID, SAML or WS-Trust.

So far, these questions are being answered on an ad hoc basis, since there are no established frameworks. I think you can divide what's happening into two approaches, both of which make a lot of sense:

First, there are relying parties that limit the use of OpenID to low-value resources. A great example is the French telecom company Orange. It will accept ID's from any OpenID provider – but just for free services. The approach is simply to limit use of the credentials to so-called low-value resources. Blogger and others use this approach as well.

Second, the is the tack of using the protocol for higher-value purposes, but limiting the providers accepted to those with whom a governance agreement can be put in place. Microsoft's Health Vault, for example, currently accepts OpenIDs from two providers, and plans to extend this as it understands the governance issues better. I look at it as a very early example of a governance-oriented approach.

I strongly believe OpenID moves identity forward. The issues of password attacks don't go away – in fact the vulnerabilites are potentially worse to the extent that a single password becomes the gate to more resources. But technologies like Information Cards will solve these problems. There is a tremendous synergy here, and that is the heart of the matter. Randall writes:

“We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. “

But I think this energy and attention will take us in the right direction as it shines the spotlight on the benefits and issues of identity, wagging identity's “long tail”.

Wide coverage of the Information Card Foundation

There has been a lot of coverage of the newly formed Information Card Foundation (ICF) in the last couple of days, including stories by mainstreet publications like the New York Times. This article by Richard Thurston from SC Magazine gives you a good idea of how accurately some quite technical concepts were interpreted and conveyed by our colleagues in the press.

Google and Microsoft are among an extensive set of technology vendors aiming to spur the adoption of digital identity cards.

The two internet giants have helped form the Information Card Foundation (ICF), which aims to develop technologies to secure digital identities on the internet and which was launched today.

Digital identity cards are the online equivalent of a physical identity card, such as a driver's license. The idea is that internet users will have a virtual wallet containing an array of digital identity cards, and they can choose what information is stored on each card. The aim is to replace usernames and passwords in an effort to improve security.

Alongside Google and Microsoft, large suppliers such as Novell, Oracle, PayPal and financial information company Equifax, have joined the ICF, as well as 18 smaller suppliers and industry associations.

“Our shared goal is to deliver a ubiquitous, interoperable, privacy-respecting federated identity layer as a means to seamless, secure online transactions over network infrastructure,” said Brett McDowell, executive director of Liberty Alliance, one of the founding members.

The idea of digital identities is far from new. But so far vendors’ efforts have been fragmented and largely not interoperable.

The ICF is proposing a system based on three parties: the user, the identity provider (such as a bank or credit card issuer) and also what it calls a reliant party (which could be a university network, financial website or e-commerce website, for example).

The ICF argues that, because all three parties must be synced in real-time for the transaction to proceed, it should be more secure.

“Rather than logging into websites with usernames and passwords, information cards let people ‘click-in’ using a secure digital identity that carries only the specific information needed to enable a transaction,” said Charles Andres, executive director of the ICF. “Businesses will enjoy lower fraud rates, higher affinity with customers, lower risk and more timely information about their customers and business partners.”

The ICF now wants to expand its membership to include businesses, such as retailers and financial institutions, as well as government organizations.

It also wants to become a working group of Identity Commons, a community-driven organization which promotes the creation of an open identity layer for the internet.

You can find thousands of similar links to the Foundation here and here. Amazing.

HealthVault moves forward with OpenID

Via Mike Jones, here's a blog post on identity issues by Sean Nolan, chief architect of Microsoft’s HealthVault service:

My plan had been to blog about this when the feature goes live later in the week. But there's been some online discussion already, and I'm sitting here at the horse show in waiting mode anyway, so it seems like now is as good a time as any to join the conversation.

The deal is — as of our next release in the next few days, users will have a new way to identify themselves to HealthVault. In addition to Windows Live ID, they will be given the option of using OpenID accounts from Verisign or TrustBearer.

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.

But why just two providers? When we were making our plans here, Chris on our partner team asked me, “Isn't this more like sort-of-OpenID?” The same question has come up online as well.*** Really, there's a very simple answer here. OpenID is a new and maturing technology, and HealthVault is frankly the most sensitive relying party in the OpenID ecosystem. It just makes sense for us to take our first steps carefully.

Both TrustBearer and Verisign have taken their obligations very seriously with their OpenID implementations. Beyond basic must-have safeguards like SSL, each offers a variety of second-factor options that provide a step up over traditional passwords — through the use of physical tokens or, in Verisign's case, the ability to associate an Information Card with an OpenID. This isn't meant to imply that there aren't other great providers out there — there are. This is just a start.

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.

This is exciting stuff — in a geeky way perhaps, but anything that begins to put strong identity technology in the hands of real users is a good thing, not just for those users, but for HealthVault and the Internet overall. Woo hoo!

*** BTW, I am clearly all about being cool and buzzword-compliant! 🙂

It's great to see an architect like Sean, who lives in Internet time and has a thousand other things on his mind, paying so much personal attention to identity issues. He's showing leadership through his commitment to phishing resistant solutions (like OpenID's PAPE and Information Cards). And he clearly embraces giving people choice.

The privacy requirements of the information he is protecting mean he HAS to do everything possible to protect peoples’ privacy. It makes complete sense to move incrementally. I hope the other OpenID providers who have clearly demonstrated their committment to strong security see the wisdom in this approach. He's opening doors. And this is the beginning of a process, not the end.

Students enlist readers’ assistance in CardSpace “breach”

Students at Ruhr Universitat Bochum in Germany have published an account this week describing an attack on the use of CardSpace within Internet Explorer. Their claim is to “confirm the practicability of the attack by presenting a proof of concept implementation“.

I’ve spent a fair amount of time reproducing and analyzing the attack. The students were not actually able to compromise my safety except by asking me to go through elaborate measures to poison my own computer (I show how complicated this is in a video I will post next). For the attack to succeed, the user has to bring full administrative power to bear against her own system. It seems obvious that if people go to the trouble to manually circumvent all their defenses they become vulnerable to the attacks those defenses were intended to resist. In my view, the students did not compromise CardSpace.

DNS must be undermined through a separate (unspecified) attack

To succeed, the students first require a compromise of a computer’s Domain Name System (DNS). They ask their readers to reconfigure their computers and point to an evil DNS site they have constructed. Once we help them out with this, they attempt to exploit the fact that poisoned DNS allows a rogue site and a legitimate site to appear to have the same internet “domain name” (e.g. www.goodsite.com) . Code in browser frames animated by one domain can interact with code from other frames animated by the same domain. So once DNS is compromised, code supplied by the rogue site can interfere with the code supplied by the legitimate site. The students want to use this capability to hijack the legitimate site’s CardSpace token.

However, the potential problems of DNS are well understood. Computers protect themselves from attacks of this kind by using cryptographic certificates that guarantee a given site REALLY DOES legitimately own a DNS name. Use of certificates prevents the kind of attack proposed by the students.

The certificate store must also “somehow be compromised”

But this is no problem as far as the students are concerned. They simply ask us to TURN OFF this defense as well. In other words, we have to assist them by poisoning all of the safeguards that have been put in place to thwart their attack.

Note that both safeguards need to be compromised at the same time. Could such a compromise occur in the wild? It is theoretically possible that through a rootkit or equivalent, an attacker could completely take over the user’s computer. However, if this is the case, the attacker can control the web browser, see and alter everything on the user’s screen and on the computer as a whole, so there is no need to obtain the CardSpace token.

I think it is amazing that the Ruhr students describe their attack as successful when it does NOT provide a method for compromising EITHER DNS or the certificate store. They say DNS might be taken over through a drive-by attack on a badly installed wireless home network. But they provide no indication of how to simultaneously compromise the Root Certificate Store.

In summary, the students’ attack is theoretical. They have not demonstrated the simultaneous compromise of the systems necessary for the attack to succeed.

The user experience

Because of the difficulty of compromising the root certificate store, let’s look at what would happen if only DNS were attacked.

Internet Explorer does a good job of informing the user that she is in danger and of advising her not to proceed.

First the user encounters the following screen, and has to select “Continue to the website (not recommended)”:

If recalcitrant, the user next sees an ominous red band warning within the address bar and an unnaturally long delay:

The combined attacks require a different yet coordinated malware delivery mechanism than a visit to the phishing site provides. In other words, accomplishing two or more attacks simultaneously greatly reduces the likelihood of success.

The students’ paper proposes adding a false root certificate that will suppress the Internet Explorer warnings. As is shown in the video, this requires meeting an impossibly higher bar. The user must be tricked into importing a “root certificate”. This by default doesn’t work – the system protects the user again by installing the false certificate in a store that will not deceive the browser. Altering this behavior requires a complex manual override.

However, should all the planets involved in the attack align, the contents of the token are never visible to the attacker. They are encrypted for the legitimate party, and no personally identifying information is disclosed by the system. This is not made clear by the students’ paper.

What the attempt proves

The demonstrator shows that if you are willing to compromise enough parts of your system using elevated access, you can render your system attackable. This aspect of the students’ attack is not noteworthy.

There is, however, one interesting aspect to their attack. It doesn’t concern CardSpace, but rather the way intermittent web site behavior can be combined with DNS to confuse the browser. The student’s paper proposes implementing a stronger “Same Origin Policy” to deal with this (and other) possible attacks. I wish they had concentrated on this positive contribution rather than making claims that require suspension of disbelief.

The students propose a mechanism for associating Information Card tokens with a given SSL channel. This idea would likely harden Information Card systems and is worth evaluating.

However, the students propose equipping browsers with end user certificates so the browsers would be authenticated, rather than the sites they are visiting. This represents a significant privacy problem in that a single tracking key would be used at all the sites the user visits. It also doesn’t solve the problem of knowning whether I am at a “good” site or not. The problem here is that if duped, I might provide an illegitimate site with information which seriously damages me.

One of the most important observations that must be made is that security isn’t binary – there is no simple dichotomy between vulnerable and not-vulnerable. Security derives from concentric circles of defense that act cumulatively and in such a way as to reinforce one another. The title of the students’ report misses this essential point. We need to design our systems in light of the fact that any system is breachable. That’s what we’ve attempted to do with CardSpace. And that’s why there is an entire array of defenses which act together to provide a substantial and practical barrier against the kind of attack the students have attempted to achieve.

Satisfaction Guaranteed?

Francois Paget, an investigator at McAfee Avert Labs, has posted a detailed report on a site that gives us insight into the emerging international market for identity information. He writes:

Last Friday morning in France, my investigations lead me to visit a site proposing top-quality data for a higher price than usual. But when we look at this data we understand that as everywhere, you have to pay for quality. The first offer concerned bank logons. As you can see in the following screenshot, pricing depends on available balance, bank organization and country. Additional information such as PIN and Transfer Passphrase are also given when necessary:

For such prices, the seller offers some guaranties. For example, the purchase is covered by replacement, if you are unable – within the 24 hours – to log into the account using the provided details.

The selling site also proposes US, Austria and Spanish credit cards with full information…

It is also possible to purchase skimmers (for ATM machine) and “dump tracks” to create fake credit cards. Here too, cost is in touch with the quality:

Many other offers are available like shop administrative area accesses (back end of an online store where all the customer details are stored – from Name, SSN, DOB, Address, Phone number to CC) or UK or Swiss Passport information:

Read the rest of Francois’ story here. Beyond that, it's well worth keeping up with the Avert Labs blog, where every post reminds us that the future of the Internet depends on fundamentally increasing its security and privacy. [Note: I slightly condensed Francois’ graphics…]

Flickr, Windows Live ID and Phishing

We talk a lot in the identity milieu about opening up the “walled Gardens” that keep our digital experiences partitioned between Internet portals. Speaking as a person who dabbles in many services, it would be really great if I could reuse information rather than entering it over and over again. I think as time goes on we will get more and more fed up with the friction that engulfs our information. Over time enough people will feel this way that no portal will be able to avoid ”data portability” and still attract usage.

Even so, many have argued that today’s business models don’t allow more user-centric services to evolve. That’s why it has been fascinating to read about the new Flickr Friend Finder. I think it is tremendously significant to see organizations of the stature of Flickr, Yahoo, Google and Microsoft working closely together so people can easily associate their pictures on one site with their friends and colleagues from others.

Once people decide to share information between their services, we run smack dab into the “how” of it all. In the past, some sites actually asked you to give them your username and password, so they could essentially become you. Clearly this was terrible from a security and identity point of view. The fact is, sharing requires new technology approaches.

Windows Live has moved forward in this area by developing a new “Contacts API“. Angus Logan gave us a great overview on his blog recently, taking us through the whole experience. I recommend you look at it – the design handles a lot of fascinating issues that we’ll be encountering more and more. I’ll just pick up on the first couple of steps:

Go to the Friend finder

Select Windows Live Hotmail (you can also select Yahoo! Mail and GMail) – I’d imagine soon there will be FacebookThe-New-Faces-at-Facebook / LinkedIn / insert social network here.

If you aren’t already authenticated, use your Windows Live ID to sign in (IMPORTANT: Notice how you are not sharing your Windows Live ID secret credential pair with Flickr – this is a good thing!)

If you have followed my work on the problems with protocols that redirect users across web contexts, you will see there is a potential problem here.

If Flickr plays by the rules, it will not learn your username and password, and cannot “become you”. It really is a step forward.

But if a user gets used to this behavior, an unreputable site can pretend to send her to Windows Live by putting up a fake page. The fake can look real enough that the user gives away her credentials.

A user called davidacoder called this out on Angus’ blog:

I think this whole approach will lead to many, many, many hacked Windows Live ID accounts. If you guys seriously believe that average users will be able to follow the rule “only type in your credentials on login.live.com” your are just naive. AND your own uber-security guy Kim Cameron is telling that very story to the world for years already. I wouldn’t mind so much if a Live ID was a low-value asset, but you bring people to associate some of their most valuable assets with it (email, calendar, contacts). I find the whole approach irresponsible. I just hope that at some point, if someone looses his credentials this way, he will sue you and present Kim Cameron’s blog as evidence that you were perfectly aware in what danger you bring your users. And to make a long story short, I think the Live ID team should fix the phising problem first (i.e. implement managed infocards), before they come up with new delegation stuff etc that will just lead to more attack surface. Very bad planning.

I admire David’s passion, although I’d prefer not to be used in any law suits if that is OK with everyone. Let’s face it. There are two very important things to be done here.

One is to open up the portals so people can control their information and use it as they see fit I totally endorse Angus’ work in this regard, and the forward-looking attitude of the Windows Live team. I urge everyone to give them the credit they deserve so they’ll continue to move in this positive direction.

The other is to deal with the phishing problems of the web.

And let me be clear. Information sharing is NOT the only factor heightening the need for stronger Internet identity. It is one of a dozen factors. Perhaps the most dangerous of these is the impending collision between the security infrastructure of the Internet and that of the enterprise. But no one can prevent this collision – or turn back the forces of openness. All we can do is make sure we apply every effort to get stronger identity into place.

On that front, today Neelamadhaba Mahapatro (Neel), who runs Windows Live ID, put up a post where he responds to David’s comment:

Earlier this week a comment was left on Angus Logan’s blog, it got me thinking, and I want to share what we are doing to create phishing resistant systems.

We are absolutely aware of the dangers of phishing on the Internet.

We understand the probability of attack goes up when the value of the asset that is being protected is higher than the strength of authentication protecting that asset – watch this video by Kim Cameron to see OpenID phished.

We have put certain measures in place to counteract phishing attempts which are listed below.

Self Issued InfoCards

In August 2007 we announced beta support for self issued InfoCards with Windows Live ID (instead of username/password). The Windows Live ID team is working closely with the Windows CardSpace team to ensure we deliver the best solution for the 400 million+ people who use Windows Live ID monthly. Angus’s commentor, davidacoder, also asked for the Windows Live ID service to become a Managed InfoCard provider – we have been evaluating this; however we have nothing to announce yet.

Additional Protection through Extended Validation Certificates

To further reduce the risk of phishing, we have implemented Extended Validation certificates to prove that the login.live.com site is trustworthy. I do however think more education for internet users is required to help drive the understanding of what it means when the address bar turns green (and what to do when it doesn’t). When authenticating in a web browser, Microsoft will only ask for your Windows Live ID credential pair on login.live.com – nowhere else! (See this related post).

Neel continues by showing a number of other initiatives the group has taken – including the Windows Live Sign-in Assistant and “roaming tiles”. He concludes:

We’re constantly looking for ways to balance end-user security/privacy and user experience. If the barrier to entry is too high or the user experience is poor, the users will revolt. If it is too insecure the system becomes an easy target. A balance needs to be struck… Using Windows CardSpace is definitely a move forward from usernames & passwords but adoption will be the critical factor here.

And he’s right. Sites like Windows Live can really help drive this, but they can’t tell users what to do. The important thing is to give people the option of using Information Cards to prevent phishing. Beyond that, it is a matter of user education. One option would be for systems like Live ID to automatically suggest stronger authentication to people who use features like data sharing and off-portal authentication – features that put password credentials more at risk.