W3C home > Mailing lists > Public > public-wsc-wg@w3.org > August 2007

Different protections for different kinds of spoofing (Was: PII Editor Bar & Trusted Browser Component)

From: Close, Tyler J. <tyler.close@hp.com>
Date: Wed, 29 Aug 2007 17:50:44 -0000
Message-ID: <08CA2245AFCF444DB3AC415E47CC40AFE86080@G3W0072.americas.hpqcorp.net>
To: "Ian Fette" <ifette@google.com>
Cc: <public-wsc-wg@w3.org>
Hi Ian,
I've responded to your points a) and b) respectively in:
In this email, I'm responding to your point c).
There are many different kinds of spoofing attacks. The PII bar proposal
text currently explains defenses against at least 4 different kinds.
Different elements of the PII bar proposal compose to defend against
different attacks. In your email quoted below, you seem to be concerned
with a Picture-In-Picture (PIP) spoofing attack, where the PII bar user
interface itself is impersonated by the attack page. The petname display
is not part of the defense against this attack. The petname helps in the
defense mounted against other kinds of spoofing attacks, as documented
in the first URL given above.
The PIP defense offered by the PII bar proposal is documented by the
second URL given above. This text currently says:

Spoofing the PII Bar

Spoofing of the PII bar itself is less of an issue than spoofing of the
URL bar, since a spoofed PII bar does not contain the user's PII text
strings and so may be recognized as a spoof. Alice's attempt to login
using a spoofed PII bar is interrupted in step 6 when she is unable to
select her password from the list of previously submitted text strings.

For robustness against spoofing, the PII bar MUST be displayed using a
theme customized to the user. The user selects this theme at browser
installation time and it remains forever the same. The icon for the
Contacts button MUST also be selected by the user at installation time.

I think there has been some study of customized chrome in the past and
the results were not promising; however, I suspect we can do better. The
Jackson study found that users attached no significance to the new style
chrome in IE7. I hope the PII bar customization will fare better because
it will be chosen by the user. I also think some habituation time will
reinforce the user's expectation that the PII bar should be displayed in
their chosen theme and that something is broken if not. Obviously, we
need to test this though.

From: Ian Fette [mailto:ifette@google.com] 
Sent: Tuesday, August 28, 2007 5:09 PM
To: Close, Tyler J.
Cc: public-wsc-wg@w3.org
Subject: Re: PII Editor Bar & Trusted Browser Component

I know we're planning to do usability studies on all sorts of things,
but I am going to bring this up at tomorrow's meeting and ideally I'd
like to get over the "But studies show X" responses that I feel are
inevitable around these topics. 

So, with that said:

Can anyone point me to the relevant papers that show
a) Just how much of a burden this is
b) That users will actually figure out that there is a problem when
they're being told to enter their username/password into some Flash
movie ( i.e. the formfiller is never triggered so PIIbar doesn't get to
show any warnings)
c) Resiliency against spoofing (i.e. if I just guess that "paypal" is
probably reasonable pii text for paypal.com and show that in a spoofed
display to the user, is the user actually going to notice that this is
not their pii text (assuming that they chose something different)

My biggest concern is that we seem to be on a warpath to say "X provides
protection because study Y shows a statistically significant difference
under some set of controls for some task", while not really trying to
quantify the burden on users and figuring out whether a) this is
acceptable under real usage b) How much dollars lost this burden
translates into and c) whether these dollars lost from b are actually
worth it. I.e. just because some users perform better in a lab study on
some task doesn't necessarily translate (for me) to "We should impose
this burden on people, which will probably result in a non-negligible
number of transactions being aborted due to user frustration, all in the
name of some marginal improvement that can still be spoofed and really
hasn't been tested to scale yet." 

That's my fear, I will q+ already for tomorrow's meeting, but ideally I
wanted to get some of it out of the way ahead of time.


On 8/28/07, Close, Tyler J. <tyler.close@hp.com> wrote: 

	I've collected together some links and more comments to help out
	tomorrow's Agenda item: "8. PII Editor Bar" [1].
	Many of the questions in TLR's first pass [2] over the PII bar
	covered in last week's telecon, as well as in my response to
	first pass [3]. I suggest looking over this response, in
addition to
	reading the proposal itself again [5]. In particular, there's
been some 
	confusion over secure attention keys, like the Windows
	sequence. The PII bar *does not* require a secure attention key.
	someone could point to the text that is causing this confusion,
	would help. 
	In TLR's email [2], he wondered about providing a secure data
	interaction for all sensitive data, as opposed to just special
	username/password data. I think our charter and our use-cases
	providing protection for a broad range of PII data, such as
credit card
	numbers, social security numbers, phone numbers, etc. Moreover,
I don't
	seen anything to be gained at this stage from focusing only on
	forms. I believe the proposed form filler changes can be made
just as
	usable as any password-only manager that can be deployed on
today's Web.
	TLR's email also supposed that both proposals "get most of their

	protection out of the
	user's lossy memory". I think both proposals actually get most
of their
	protection from the data entry interaction, not on any reliance
on the
	user's not remembering sensitive data. I agree there is useful 
	protection to be had from freeing the user from the task of
	passwords, and that both proposals enable this.
	I think the remaining parts of TLR's email need to be presented
in more
	detail to be effectively examined. Thomas, what do you think
	phrasing some of your questions in terms of our use-cases [6]?
	example, picking one that you think reveals a shortcoming and
	pinpointing the exact moment where the user may be tempted to
follow a
	detrimental course. 
	[1] "Agenda: WSC WG weekly 2007-08-29"
<http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0157.html >
	[2] "PII Editor Bar & Trusted Browser Component from Thomas
Roessler on
	2007-08-16 (public-wsc-wg@w3.org from August 2007)"
<http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0127.html> >
	[3] "Rachna's first cut at a usability analysis of PII bar"
	[4] "RE: first cut usability walk through from Close, Tyler J.
	2007-08-06 ( public-wsc-wg@w3.org from August 2007)"
<http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0029.html >
	[5] "Personally Identifiable Information (PII) Bar"
<http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor >
	[6] "Note - use cases"
	-----Original Message-----
	From: public-wsc-wg-request@w3.org
	On Behalf Of Thomas Roessler
	Sent: Thursday, August 16, 2007 10:19 AM 
	To: public-wsc-wg@w3.org
	Subject: PII Editor Bar & Trusted Browser Component
	I'm reading through the latest state of the PII Editor Bar
	and also the Trusted Browser Component proposal again. 
	There are a number of differences on a detailed level -- e.g.,
	petnames vs generic shared secrets, and some stuff like that.
	I *think* the one significant difference between the two is that
	Editor Bar proposes a different interaction ritual for generic 
	forms, and requires significant customization (i.e., the "data
	entry" task is redesigned), while the Trusted Browser Component
	seems to focus on a single high-level task ("login to XXX") and
	introduces a new (possibly simpler?) user interaction for that
	narrow task.
	Both proposals seem to get most of their protection out of the
	user's lossy memory (if people don't remember passwords, they
	easily hand them over), and the broken interaction flow when
	log in to an unkown site that they think is the one they were at
	Both proposals include some social engineering to steer users
	a site they've dealt with before in certain failure cases, by
	it easy for them to find out about "existing relations" during
	interaction that would lead to data entry with the site they
	currently deal with (and caching of that data / passwod).  I
	that part, and would love to see some empirics on the effect.
	PII Editor Bar gets a second level of protection out of a
	petname-like UI paradigm; the Trusted Browser Component assumes
	some kind of shared secret has been established to create a
	path to the user.  Mentally going through possible scenarios,
	suspecting that this particular element of the respective
	is the weakest one. 
	As we move forward, I would like to see both concepts -- the
	form filler, and the task-specific approach -- tried out and
	analyzed.  I have a gut feeling that the task-specific approach
	the Trusted Browser Component suggests might have larger chances
	deployment and user acceptance, based on ease of use when people
	in to sites.
	It might in this context be worth looking at the difference
	approaches that (a) require a secure attention key, (b) require
	secure attention key and tell the user about it ("to login to
	please push blah", maybe in one of the nice yellow
	chrome-overlapping bars), and (c) don't require a secure
	key, but simply replace the login interaction. 
	(Example: PII bar seems to require that a secure attention key
	pressed for every single form field.  TBC seems to only require
	specific interaction to either put a session into a specific
	or maybe to effect a login transaction.) 
	Additionally, it might be an interesting exercise to abstract
	step further, and beyond documenting the specific approach that
	comes out useful as a secure data entry ceremony, also write up
	general requirements for secure, interactive credential
	and/or login processes.
	Thomas Roessler, W3C  <tlr@w3.org>
Received on Wednesday, 29 August 2007 17:52:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC