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

Hi Tyler,

I'd be interested in hearing more about this...  Do you have any URLs I
could check out for some more background info?

I don't want to get too mired in the technical description but...  I can
see how this might foil a phishing "site", per se, but would it also be
able to foil instances where a phishing form is injected via XSS into a
trusted site?  This could happen by either injected the form code in the
URL itself or by sourcing an external page.  For example, if a trusted
login form is susceptible to XSS attacks, then an attacker could insert
his own login form that would, according to the browser address bar, be
sourced from the trusted site while posting the data elsewhere.  I
haven't seen this too much "in the wild" so I'm really not sure if
current anti-phishing countermeasures can address it either.

Thanks,
Shawn

Close, Tyler J. wrote:
> 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.
> 
> 
> 
> 
> 
> 
> 

-- 
shawn duffy - sduffy at aol dot net
senior technical security engineer | aol operations security
703.265.8273 | AIM: ShawnDuffy1

Received on Tuesday, 27 March 2007 13:37:23 UTC