[OpenID] OpenID and phishing

[Mike Beltzner]

----- Ka-Ping Yee <openid at zesty.ca> wrote:
> On Sat, 20 Jan 2007, Chris Messina wrote:
> > I want to underscore what Scott's said -- especially around the
> part
> > that OpenID will stop and/or prevent phishing. Mike's likening
> > phishing to XSS or buffer overruns is a great way to think about:
> it's
> > simply one of those dark aspects of being on the web that requires
> a
> > host of best practices (and sometimes luck) to avoid.
> 
> No, this is not a good analogy.  Deploying OpenID has no effect on
> the
> incidence of buffer overruns.  Deploying OpenID *does* significantly
> increase the risk of phishing.

You're misunderstanding the point that Chris and I are making. We're suggesting that phishing is becoming another nebulous security concern that will have to be taken into account when any new technology -- be it a specification or an implementation -- is being authored. Just like developers and technologists will need to take care to not build things that are less vulnerable to buffer overrun attacks (ie: taking care in their implementations, using more managed code) I think that they'll need to take care not to build things that are more vulnerable to phishing attacks.

Again, we're agreeing, and I think you'll find that assuming that things are black & white (ie: that either people care about phishing, or that they don't) will make this conversation ultimately less fruitful.

So let's work together so that deploying OpenID *doesn't* neccessarily mean significantly increasing the risk of phishing (eg: "no regressions") but not be so specific that the OpenID specification ends up limiting future implementations that might, as Chris says, be smarter than us and have better ways for preventing phishing.

To be clear: I agree that as specified, OpenID lacks the approprite level of concern about the fact that we're relying on RPs to be pretty honest, or on UAs to identify when you're actually at your OP. So let's figure out how we can solve that problem while meeting the original goals of OpenID, which were to be, you know, decentralized and "open". :)

> > to try to dictate how OpenID must look or behave beyond the
> > bit passing level is going to be an uphill battle...
> 
> I agree with you that it's not a protocol spec's job to dictate the
> UI.
> It *is* the spec's job to clearly warn implementors that OpenID
> increases
> phishing risk for the standard login UI -- used by most current
> OpenID
> providers and demonstrated in practically every explanation of OpenID
> --
> and that they are responsible for taking measures to prevent it.

Yup.

> > I feel that it's impossible for us to mandate or legislate matters
> > that we don't fully understand, don't have the influence to enforce
> 
> The spec should openly acknowledge that the current practice, which
> is
> also the most illustrated practice, is not safe, and outline why.

Yup.

> Suggestions as to how to make it safer, as long as they actually work
> (and i don't mean perfectly, but at least well enough to make OpenID
> no worse than the status quo) are worthwhile to provide as
> suggestions
> but not to legislate, as you say.
> 
> On the other hand, it is probably a good idea to legislate or
> strongly
> recommend *against* the specific practice we know to be dangerous --
> redirecting from a validation request straight to a username/password
> login form -- and this practice should not be used in examples.
> 
> Can we agree on that?

Yup.

cheers,
mike