Rec Proposal: Separate in-browser editor for entry of Personally Identifiable Information (PII)

During the March 20th telecon, our January f2f and in a mailing list
proposal way back in December, I put out some seeds of something I would
like our WG to work on as a recommendation. Much of this proposal is not
novel, but a combination of elements I've seen in other anti-phishing
proposals, including Rachna's Security Skins work, Ka-Ping Yee's Passpet
work, the Safe Browsing Mode the FSTC folks have talked about, Min Wu's
Web Wallet, browser password managers and form fillers, and my own
Petname Tool work.

Following the categorization of use cases in the Note, this proposal is
intended to address use cases where:

    Destination site: any
    Navigation: any
    Intended interaction: submission of sensitive information
    Actual interaction: submission of sensitive information

As described in this email, I think the proposal addresses use cases:
1,5,8-10. After discussing these use cases, I think the proposal can be
extended to cover additional use cases.

The proposal is intended to address the following problems documented in
the Note:

    - Provide a chrome-like area that is less vulnerable to spoofing
    - Provide a chrome-like area with a well defined role
    - Present information that is both understandable to the user and
useful in making trust decisions
    - Integrates the consumption of security information into normal
browsing activities
    - Makes it apparent to the user when a new trust decision is about
to be made

In use case 1, I think the crucial piece of information Alice needs to
proceed safely is confirmation that she is securely connected to the
same entity she has given her bank login credentials to in the past.
Given this information, Alice knows there are no new trust decisions to
be made and so her normal login habits can unfold uninterrupted.

I think an ideal UI should quietly streamline Alice's web surfing
habits, but interrupt if a new trust decision is about to be made. For
this functionality to be possible I think it is necessary, but also
sufficient, for Alice to indicate to her browser that she is providing
Personally Identifiable Information to a web site. I think this hook is
sufficient to enable the browser to help Alice safely repeat past trust
decisions, but alert her when she is about to make a new trust decision.

I propose adding a new chrome-like area to the browser for entry of
Personally Identifiable Information (PII). One function of this PII bar
is providing a text field for user entry of PII text strings. From a
feature perspective, this PII bar is similar to Min Wu's Web Wallet, but
the user interface has more in common with the form fillers in today's
web browsers. The text field provides a menu of PII text strings
previously provided to the entity hosting the current web page, supports
auto-completion when typing one of these text strings, as well as user
entry of an entirely new string. It is important that the
auto-completion and menu selection only support entry of PII text
strings previously provided to the entity serving the current web page.
The goal here is to facilitate repetition of a past trust decision, but
make it apparent when a new trust decision is being made.

In use case 1, Alice has previously provided her login credentials to
her bank, and so using the PII bar, she logs into her bank by selecting
the login credentials from the menu provided by her PII bar, rather than
typing them in herself. In particular, Alice's normal login ritual might
be:

    1. Alice positions the keyboard focus in the username text field, or
the web page puts it there automatically on page load.
    2. Alice hits an attention key which moves the keyboard focus to the
PII bar text entry field.
    3. Alice selects her username by either:
        3a. using the up or down arrow key to select the corresponding
text string from the menu of previously provided PII text strings
        3b. typing the corresponding text string until enough characters
have been provided for auto-completion
    4. Alice hits the Enter key, causing the PII bar to paste the
selected text string into the UI widget that previously had the keyboard
focus and return the keyboard focus to that UI widget
    5. Alice moves the keyboard focus to the password text field, or the
web page does that for her.
    6. Alice repeats steps 2 through 4 for her password.

In the typical case, this login ritual is longer than that supported by
current password managers or form fillers, but I think it provides some
important advantages.

A. It can be reliably implemented. Today's password managers often
succeed at guessing the location of many login fields, but sometimes
fail, requiring the user to enter the information afresh. This failure
mode is highly susceptible to phishing. It also legitimizes failure,
which a phisher can exploit to convince the user that an attack is just
a normal implementation failure. We should also keep in mind that web
content types are currently undergoing change with the introduction of
new HTML tags, Flash, etc. and should be expected to continue to evolve
in the future. We need a user interaction that can be reliably and
quickly implemented as new web content types are deployed. Any lag in
keeping up with new content types provides an opportunity to phishers.

B. It is reusible for all PII text string types. The same procedure can
be used to enter a SSN, credit card number, phone number, etc. The set
of possible PII text strings is large and open. I don't think a browser
implementation can successfully guess the location and type of a PII
text string entry field when it is an open set and there are no
standards for marking their presence.

C. It supports the deployment of new PII types. Instead of hard coding
knowledge of different PII text string sets, or cards in the Web Wallet
terminology, these sets are defined by the microformats that naturally
evolve in the web page's content type. The microformat defines the set
of PII strings and the expected entry order. The user enters these
string collections in the same way described for a ( username, password
) pair.

D. I think the procedure correctly walks the user through the set of PII
text strings they are providing in the current request. I think it is a
mistake to make it easy for the user to submit a set of PII text strings
without review.

E. The user actively indicates they wish to use the form filler and so
the browser doesn't need to pop a dialog asking if it is OK to remember
the entered text string.

F. It is tempting to save Alice some keystrokes by facilitating entry of
PII text strings given to other entities, but not yet the current one,
but I think doing so is a mistake. If Alice is about to make a new trust
decision, she should be given the opportunity to make a deliberate
decison, rather than hurried into making an ill-considered one. I think
the situation is directly analogous to the writing of a paper bank
check. Even though the amount of the check is already present in digits,
the check requires the user to write out the amount in long-hand to
ensure the user does not proceed in haste. Similarly, I think completely
typing in the PII text string affords the user the opportunity to
recognize and consider a new trust decision.
    
An attack mode for use case 1 occurs when Alice is not at her bank's web
site. For the case where Alice has no relationship with the imposter web
site, Alice's login ritual is interrupted in step 2 when she hits the
attention key. At this point the PII bar contains a disable text entry
field and displays a message indicating that Alice has not created a
relationship with the entity providing the current web page, or "You're
talking to a stranger".

An alternate attack mode for use case 1 occurs when Alice does have a
relationship with the entity hosting the current web page, but the
entity is not her bank. In this case, Alice's login ritual is
interrupted in step 6 when she is unable to select her bank password,
since it is not available to be selected. Since the displayed web page
may look exactly like her bank's login page, the URL may be confusingly
similar and her username may be identical for both sites, we need an
additional indicator to help Alice sort out this mess. (If her password
is also the same, we've already lost, since the attacker already has
everything he needs.) We've temporarily succeeded in interrupting the
ill-fated login. We must now quickly tell Alice what's going on and how
to proceed before she forges ahead and types in her password manually.
Immediately adjacent to the PII bar text entry field is a Petname Tool
<https://addons.mozilla.org/firefox/957/>. The Petname Tool indicates to
Alice, *in her own words*, what entity she is currently interacting
with. Hopefully, Alice now realizes something strange is going on, but
she still wants to do some banking and she intends to proceed, one way
or another (see Stuart's recent study, "The Emperor's New Security
Indicators"). Immediately adjacent to the Petname Tool is a button which
when pressed provides a menu of all of Alice's relationships (exactly
the same as the bookmark list generated by the Petname Tool). From this
list, Alice can select the entry for her bank, which directs the current
browser window to her bank's login page, just as selecting the bookmark
for such a page would. Alice can then proceed to login normally.

The bootstrap case for use case 1 occurs when Alice first sets up her
bank account for use with the PII bar. This scenario unfolds just like
the first attack scenario; however, in addition to the message "You're
talking to a stranger", the PII bar displays a summary of the
information available in the SSL server certificate. For example, the
following may be displayed:

    Super CA Inc. claims this web site belongs to "Big Bank Inc.", which
is incorporated in Sunnyvale, California, USA.

At this point the user can choose to create a new relationship by typing
a petname into the Petname Tool. Doing so will enable the PII text entry
field. The user can then initialize their username and password.

The user should scan the list of existing relationships before creating
a new one to ensure they are not being duped. The Petname Tool should
help here by comparing the user chosen petname to the already chosen
petnames and point out potential confusion.

The role of the PII bar is solely the tracking of PII text strings. No
other functionality should reside here. All of the displayed information
either comes directly from the user, or, exclusively in the bootstrap
step, is text marked as quoted from a certificate. Special care must be
taken for the display of the text taken from the certificate to ensure
the user realizes it is potentially misleading information obtained from
a third party, and who that third party is.

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. However, for robustness, I
recommend that the PII bar be displayed using a theme customized to the
user. The user selects this theme at browser installation time and it
remains forever the same. For example, Firefox could have the user
select randomly from one of the over 300 themes available from their
addon site. This randomly selected theme provides the same beneficial
security offered by Rachna's Security Skins, but is hopefully more
beautiful in the eye of the beholder.

Note that the "attention key" need not be implemented as a secure
attention key like Window's CTRL-ALT-DEL combination. The keypress is
simply one which the browser recognizes as one intended for its
consumption, rather than the web page's. It is OK if the web page can
spoof the hitting of the attention key.

I've now round tripped one use case, but this email is already pretty
long, so I'm going to defer doing another use case to another email.
Hopefully I've already provided sufficient detail for feedback.

Tyler

This email addresses ACTION-162.

Received on Wednesday, 21 March 2007 02:25:33 UTC