[OpenID] OpenID and phishing

Chris Messina chris.messina at gmail.com
Sun Jan 21 09:37:18 UTC 2007


Well, given your example of the image tag, for one thing, delivery of
the page's data and its subsequent rendering don't fail if an alt
attribute is missing even if the spec demands it... Now, take the more
crucial example of OpenID and suggesting that folks *must* use
non-critical markup "merely" to help prevent abuse that is prevalent
today and you're starting to stray outside the focus of the spec.

Furthermore, XHTML, as has been pointed out, may not be the only
interface by which someone logs into their account: consider Flash
logins, XAML, Apollo and the like... languages and binaries that are
not necessarily easy to solicit such "identifying marks" from.

And lastly, what should the UA do in the case of a login form that
self-identifies as you suggest, but is not at all what it claims to
be? Can or should the UA be able to disambiguate a real from a fake?
Or to somehow know when the markup you're suggesting is being used
correctly?

I am very eager to make using the web safer and more friendly, just as
I'd like to rid the streets of criminals and those who prey on the
weaknesses or unfamiliarity of others... but these issues have existed
for humans amongst humans for eons. Let's certainly not make the
situation worse -- but let's be careful that our remedies too don't
make us become more comfortable or less vigilant than one must be to
navigate these highly unregulated waters. We are not in the position
to create a surrogate for digital literacy or self-awareness -- to do
so actually puts more people at risk for relying on false safety
measures -- and ultimately throws the trajectory of this project off
course.

There have been some excellent suggestions, ideas and even
implementations thrown out -- and I would strongly encourage them all
to be added to a Phishing-brainstorming page, including Marcin's. I
also would like to follow up on Scott's action items and decide how
best to include the concerns and very real dangers that OpenID or any
remote authentication system (including BBAuth and GAuth) possess in
the spec, and perhaps most importantly, start to develop the language
with which we talk to others about these matters.

Chris

On 1/20/07, Marcin Jagodziński <marcin.jagodzinski at gmail.com> wrote:
> Maybe my view at specs is biased, I'm coming from web development
> world, where specs and reality we two different realms. But no one
> wanted eg. the "alt" attribute to be removed from specs just because
> images were displayed even when "alt" is omitted and there are many
> pages, where "alt" is omitted. "alt" is mandatory for <img> tag. The
> same situation here.
>
> I don't think that if OP MUST include claim (to UA, not to RP) "I am
> OP" in any form, the RP MUST check it and whole transaction MUST fall
> if OP does not claim this.
>
> But maybe you're right, that this is out of scope, I'm not insisting
> on putting it into specs. I'd feel much safer if it will be used, not
> just specified.
>
> regards,
>
> Marcin
>
> > On 20-Jan-07, at 12:21 PM, Chris Messina wrote:
> > > I'm confused on this idea, I think... What happens if someone
> > > *doesn't* comply with this? Will the protocol break? Will login fail?
> >
> > Exactly! As much as I would like to have these as MUSTs in the real
> > world, I don't see a way to put them in the spec as requirements.
> >
> > Having a MUST implies that, if it is not complied with, the party at
> > the other end of the transaction MUST fail. And therein lies the
> > problem: OP - end user authentication is out of scope of the OpenID
> > spec. If it weren't, an OpenID-speaking entity would be needed on the
> > user side during that transaction.
> >
> > no-password.com can be a compliant OP, if it (and its users) choose
> > to not care about security at this stage.
> >
> > So the only way to tie the OP - end user authentication with the spec
> > is with security recommendations for the OPs that *are* concerned
> > with security. And this part is currently mentioned in the spec, by
> > acknowledging the attack and pointing out that a secure channel
> > between the OP and the user is needed to prevent it.
> >
> > Of course, the problem remains if no-password.com markets itself as
> > super-secure-op.com, fools users into using it, and later on the
> > users want to use these identities to login to their banks.
> >
> > So the issue (as I see it) is making the users aware that, if online
> > identity is important to them, the trust associated with the
> > relationship they have with their identity "keepers" - the OPs -
> > should be similar to the trust they have in their banks for keeping
> > their money.
> >
> >
> > Johnny
> >
> >
> >
>


-- 
Chris Messina
Citizen Provocateur &
  Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is:   [ ] bloggable    [X] ask first   [ ] private


More information about the general mailing list