=victor.grey weblog

Many of the tech and crypto people working on phishing mitigation seem to think that the problem is “how can I connect with anyone in the world in a trustworthy way?” Personally I don’t think it’s all that compelling to be able to communicate with 6 billion strangers. It’s much more interesting to be able to communicate from anywhere with people whose identity and reputation within my circle of communities can be ascertained in a trustworthy way.

OpenID was originally created to mitigate comment spam on weblogs, and it remains excellent for that purpose. Having to prove that you are in control of some (any) website adds enough friction into the process to make robotic spamming less attractive.

The evolution of OpenID as a more general identifier, and the mutual adoption of support for i-names in OpenID and support for OpenID as the primary SSO protocol by the i-names community, has underlined some issues long understood in certain rarefied circles, but only now being discussed in the larger world of OpenID developers. See OpenID Phishing Brainstorm.

The reason that most of these suggestions amount to security theater is that phishing does not rely on snaring a large percentage of its potential victims. In fact a very tiny rate of success can be quite profitable for the attacker. If a small number of the potential victims are tired and/or in a hurry, and fail to notice or choose to ignore the discrepancies in the process, the attack will be successful from the attacker’s point of view. If there is anyone reading this who has never made a mistake on a computer because they were tired or impatient, feel free to exempt yourself from this analysis.

Perfect and unfailing vigilance is not a human trait. Instead we trust, meaning that we enter into a very familiar process with the expectation that it is in everyone’s self-interest to follow the rules and/or that if we encounter any actors who are not following the rules it will be immediately obvious. We drive down the street “trusting” every unknown driver passing in the opposite direction to stay on their side, mainly because there is no case where it is not in their self-interest to do so. (Many years ago, a co-worker of mine was driving home from work very late in the evening. His was the only vehicle on that stretch of the interstate. Imagine his shock, confusion, horror even, when he saw a big semi coming down the highway in the opposite direction on his side! He pulled way over to the right and let it go by, and we can only assume, since there were no reports of an accident in the news, that the truck driver realized his mistake and turned around or got off the next exit.)

The underlying vulnerability in the SSO process is that the principal is being asked to trust an RP, and the RP is being asked to trust an OP. To justify that trust, the RP must properly identify itself to the principal, and its self-interest must be known. The OP in turn must identify itself to the RP. In other words, we must not cross trust boundaries. If we are envisioning an open distributed system that will work for the principal whether they are using their home computer, their iPhone at the airport, or an internet cafe in Budapest, then we can’t depend on any browser plugin or local software. Instead we need to find a way for the principal to put bounds on an otherwise unbounded process, to stay within trust boundaries. All of the permitted actors must share some kind of self-interest for there to be trust.

There are two ways to create trust boundaries. The actors can all be part of some circle of trust, all known to each other. Or, if we wish to create a system in which strangers can interact, then we must have some kind of reputation and/or introduction system. Either way, we must always start at a known trusted location, and follow only trusted links from there. An OP must not accept requests for authentication from an unknown RP. Putting up a screen asking the user if she wants to accept an authentication request from an unknown RP does not work—Microsoft has spent years conditioning users to click “yes” to anything in a desperate attempt to get the damn computer to allow them to get on with their day.

Phishing, remember, is based on hooking the tired, distracted and harassed. A secure system must make it impossible or at least very difficult for the user to do the wrong thing, and not depend on the user to be paying attention.

Online communities can act as trust boundaries for their users. Online communities can affiliate with one another, creating expanding reputation and search networks. They must vet their users in some understood way, and that method of vetting is part of the community’s reputation. The user must only be able to enter the system through their home community’s gateway.

Ordinary phishing is not solved by this scheme—users still need to be educated about email scams and developers need to guard against cross-site scripting. But the big new vulnerability opened up by OpenID and other SSO schemes, caused by the promiscuous redirection of the user by potentially unknown RPs, can be prevented if it’s understood to be the result of violating trust boundaries.