[cap-talk] Update on petname related anti-phishing work at theW3C

[Tyler Close]

On 6/27/07, Karp, Alan H <alan.karp at hp.com> wrote:
> Tyler Close wrote:
> >
> > > You state in 5.2.1 "Pressing the enter key with the
> > keyboard focus in
> > > the text field transfers the displayed text string to a
> > corresponding
> > > field in the currently displayed web page."  How do you
> > know which field
> > > is the corresponding one?
> >
> > The one that previously had the keyboard focus. This is explained in
> > greater detail further down in the proposal.
> >
> That might be confusing.  We have enough trouble teaching people how to
> set up a password using the HP Anti-phishing toolbar, and there it's
> only password fields.

That's a more complicated operation. The PII bar interaction is the
same as the current form filler, but the drop down has been moved to
the bottom of the screen, instead of immediately below the text field.

>  If filling out a form involves several trips to
> the toolbar, users might be tempted to use other form filler tools.  Can
> you also record enough information to locate the proper field for each
> piece of PII and fill in all the requested info in a single go?

I think there has to be explicit user involvement or banks and other
sites won't support it. Major banks have blocked browsers, such as
Opera, that auto-fill password fields.

See the second to last paragraph in:

http://www.w3.org/2006/WSC/drafts/rec/#piieditor-conformance-selection

> > > Does the user's password in the tool appear in the clear or
> > obscured?
> >
> > I was thinking in the clear, but I realize some people may balk. What
> > do you think?
> >
> I would choose the format used on the web page.  Since you know where
> the text is going, you know how text is displayed in that field, don't
> you?

Not necessarily. I could be form filling Flash or a Java applet.

Also, seeing your password in the PII bar is part of what tells you
you're looking at the real PII bar and not a spoof. Does your password
really need more protection from shoulder surfing than your credit
card number gets, or other PII strings get?

> > > 5.4.3: Does this approach address the "Bank of the VVest" problem?
> >
> > I think so. Can you explain the threat in more detail?
> >
> "SuperCA Inc. claims this web site belongs to 'Big Bank Inc.', of
> Sunnydale, California, USA".  The presumption is that Alice trusts what
> her tool presents.  Say she banks at Big Bank in Sunnyvale, and the tool
> presents the string "Big Bank of Sunnydale".  Not noticing the
> misspelling, she might think the tool "lost" her PII and reenter it.

This attack gets caught in a few places. The first message from the
PII bar reminds you to check for an existing relationship. If you blow
right by that, then hopefully the user will enter a similar petname,
in which case the browser will find the collision. Finally, none of
this certificate information even gets displayed if the certificate
doesn't come from a trusted CA. Hopefully trusted CAs won't issue such
a deceptive cert. But even if they do, the first two checks should
hopefully prevent the attack.

> > > 5.7.2: Perhaps I got a new credit card number because I realized I'd
> > > been phished.  In that case, I don't want the new number to
> > appear to
> > > have been given to places that got the old number.
> >
> > Are you saying you want to be able to delete a petname and its
> > corresponding history?
> >
> I'm wondering if automatically showing the new credit card number as
> having previously been submitted to sites that got the old one might
> make it too easy to give the new number to the same spoof site.  Perhaps
> the display could be set up to indicate that this replacement data is
> equivalent to what was previously sent to the site but hasn't been sent
> yet.

I'm worried about the complexity of presenting this much information.

Currently, all the statements in this area are SHOULDs, left in the
hands of the implementor. I'm tempted to avoid going into too much
detail here.

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/