This page documents a proposal for the RecommendationDisplayProposals.

Safe Web Form Editor

Goals

This recommendation supports the following WSC goals:

Overview

User studies of phishing have commonly found that user agent security indicators go unnoticed by users in both normal use and attack scenarios Out of sight, out of mind. In a way, this is as it should be, since in many scenarios, security information is not of great importance and so the user should not be distracted by it. However, in some scenarios, security information is crucial and so an interaction that ensures user awareness of this information is desirable.

Pulling the user's attention away from their primary task is intrusive and little tolerated by users, a phenomena confirmed in user studies Poor usability of dialog boxes. To remain effective in the long term, an interaction seeking to bring attention to information outside the user's locus of attention must always be seen as relevant and useful by the user and support habit formation to minimize disruption to the user's work flow.

To achieve this level of context sensitivity, this recommendation proposes a new user-driven interaction for entry of information deemed security critical by the user. This new interaction integrates consumption of relevant security information by the user while facilitating the data entry task and providing a record of the user's trust decisions.

This recommendation is an extension and modification of the form filling feature found in many user agents. The core conceptual change is augmenting the form filler with a record of what web site a stored text string was given to and providing the user with ready access to this record during a data entry task. The user interface to the form filler should facilitate repetition of a past trust decision, such as re-sending an identifier to a web site it has been sent to in the past, but alert the user when a new trust decision is being made, such as sending an identifier to a web site for the first time.

Desktop web browser implementation

To facilitate a more detailed description of the recommendation, this section describes a conforming implementation of a desktop web browser.

The chrome area at the bottom of a desktop web browser, which typically contains a status bar is replaced by a new chrome area which houses the new user interface to the form filler. This new user interface is called the "editor bar". A possible realization is shown below:

At the far left of the editor bar is the "contacts" button. When pressed, this button displays a list of links to each web site the user has sent identifiers to using the editor bar. The hypertext of each hyperlink is a user chosen name for the web site, called a petname. The petname for the currently displayed web site is displayed in the "petname tool" which is the editable text field immediately adjacent to the contacts button. If the user has not assigned a petname to the currently displayed web site, the petname tool displays the string "no history". Immediately adjacent to the petname tool is the "text entry tool"; a text field for user entry of text strings. The arrow button attached to the text entry tool displays a list of all text strings the user has entered into the text entry tool, along with an indication of whether or not the text string has previously been sent to the displayed web site. Selecting a string from the list copies it to the editable text field. 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.

The full functionality of the Safe Web Editor is further described in the Use-cases section, using the terminology introduced here. The complete design aims to leverage the following usability principles:

Dependencies

This proposal relies upon the following security information:

Use-cases

Following the categorization of use cases in the Working Group's Note, this proposal specifically addresses use cases where the user is providing information to a web site, though the proposal can be extended to cover additional use cases. Information about the destination of a hyperlink navigation is used, but none about the source. This proposal can be made to work with both desktop browser and smartphone user agents.

Plain scenario

For the plain scenario, 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.

For this scenario, we assume Alice has previously provided her login credentials to her bank using the editor bar. To login anew, she selects her login credentials from the menu provided by her text entry tool, rather than typing them in herself. In the worst case, Alice's login scenario is:

  1. Alice positions the keyboard focus in the username text field of the displayed web page.
  2. Alice hits an attention key which moves the keyboard focus to the text entry tool.
  3. Alice selects her username by either:
    • using the mouse to click on the corresponding text string shown in the menu of previously provided text strings
    • using the up or down arrow key to select the corresponding text string
    • typing the corresponding text string until enough characters have been provided for auto-completion
  4. Alice hits the Enter key, causing the editor 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.
  6. Alice repeats steps 2 through 4 for her password.

With some assistance from the web page, this login ritual can be much simplified. Alice's username may be pre-filled by the web site and the keyboard focus put in the password text field on page load.

  1. Alice hits an attention key which moves the keyboard focus to the text entry tool.
  2. Alice selects her password from the provided menu
  3. Alice hits the Enter key, causing the editor bar to paste the selected text string into the displayed web page, after which the web page submits the login form.

In the above case, Alice's normal login ritual requires two keypresses and one mouse click (or another keypress).

Bootstrap scenario

The above plain scenario assumes Alice has already initialized her editor bar's relationship with her bank. In the bootstrap variation of this scenario, Alice has not yet done this initialization and so the normal login ritual is interrupted in step 2 when Alice hits the attention key. In response, her user agent displays a message indicating the lack of history, such as:

If the user selects the first option, the hyperlink list displayed by the Contacts button is displayed.

If the user selects the second option, the following message is displayed:

If the user selects the first option, the browser navigates to the user's preferred search engine.

If the user selects the second option, the browser searches the database of existing relationships to find any petname similar to the newly chosen one. If any matches are found, the user is notified of the collisions and given the opportunity to instead navigate to the corresponding web site. If no matches are found, the browser updates its database of stored relationships, enables the editor bar and puts the keyboard focus in the text entry tool. The login ritual then resumes at step 3.

Impostor attack on plain scenario

If Alice has established a relationship with her bank's web site, but not the imposter web site, the login attempt at the imposter site is interrupted at step 2. Instead of proceeding directly to step 3, the browser displays the bootstrap message.

A more advanced attack occurs when Alice has established a relationship with her bank's web site, and another with the imposter web site, under a different pretext. In this case, the login attempt is interrupted at step 6. Alice is unable to select her bank password since the text entry tool does not list it as a text string previously submitted to the current web site. The petname tool also displays the name chosen for the imposter site, instead of the one chosen for the bank site. To avoid the attack, Alice must click the Contacts button to navigate to her bank's web site. The editor bar should display a message instructing Alice to do this when she fails to select a previously submitted text string.

If Alice has not established a relationship with either the bank's web site, or the imposter web site, the login attempt at the imposter site is again interrupted at step 2 and the bootstrap scenario unfolds. To avoid the attack, Alice must realize that the presented web site credentials are unacceptable and so instead search for the expected bank web site.

Spoofing the editor bar

Spoofing of the editor bar itself is less of an issue than spoofing of the URL bar, since a spoofed editor bar does not contain the user's secret text strings and so may be recognized as a spoof. Alice's attempt to login using a spoofed editor 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 editor 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.

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; the features described above enable detection of a spoofed editor bar.

Expected user behavior

Understanding of security sensitive identifiers

A core assumption of this proposal is the expectation that users know what identifiers should be treated as security critical and so be entered using the editor bar. For example, the user must realize that their password or credit card number should be treated with care. To encourage such treatment, the interface is designed such that it is easier to provide information to a web site using the eidtor bar than it is for the user to enter information into a web page directly. When using the eidtor bar, the user need not remember the exact sequence of characters in a text string, nor type them in; rather, the string is selected from a menu.

User trust in user agent

This proposal assumes the user will trust their user agent to keep a record of sensitive identifiers.

Tendency to use the same name for the same entity

If a user has created a large number of relationships using the editor bar, but has not created a relationship for all entities that secrets are exchanged with, the user is vulnerable to an imposter who tricks the user into creating a new relationship. The proposal defends against this attack by detecting an attempted reuse of a petname. This detection is either manually done by the user, if the first option presented by the bootstrap scenario is selected; or automatically by the browser if the user proceeds with the second option presented by the bootstrap scenario. For this defense to work, it must be the case that the user will tend to use a similar name each time they try to identify the entity they expect to be interacting with.

Disruption

Longer login ritual

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

Local database dependency

Like current password managers and form fillers, the editor bar relies upon a local database. For users with multiple computers, the utility of the editor bar is dependent upon the user agent's ability to synchronize settings across installations.

Conformance

Associating a history with a web site

The editor bar keeps a history of text strings the user has given to a web site via a special purpose text entry tool. This section specifies the algorithm the user agent MUST use to determine if a visited web site should be considered the same as one in the history database. This algorithm is based solely on a comparison of information provided by X.509 certificate chains. Let the currently visited web site be SiteA and a candidate match in the stored editor bar history be SiteB. For each certificate chain received from SiteB, attempt a match against the one received from SiteA using the following checks:

  1. If both SiteA's and SiteB's certificates are currently valid and they specify the same public key, there is a match; otherwise, continue with the matching algorithm.
  2. If SiteA's certificate was issued by a different certificate authority than SiteB's certificate, there is no match; otherwise, continue with the matching algorithm. Two certificate authorities are considered the same if their certificates are identical, or if they are both installed as trusted certificate chain roots identified by the same name in the user agent's presentation to the user.
  3. If both SiteA's and SiteB's certificates specify the same value for the "CN" field, there is a match; otherwise, continue with the matching algorithm.
  4. If both SiteA's and SiteB's certificates specify the same values for all of the "O", "L", "ST" and "C" fields, there is a match; otherwise, continue with the matching algorithm.
  5. The algorithm ends here with no match.

The user agent MUST retain sufficient information about all the certificate chains used by a web site to find a match in all cases where the above algorithm indicates there is a match.

The first check in the matching algorithm, which compares public keys, provides a means to transparently update the certificate authority used by a web site. To change certificate authorities, a site acquires a certificate for its existing public key from the new certificate authority. The site should continue using its existing public key until its user base has received the new certificate chain through visits to the site.

Both the first check in the matching algorithm and the second to last, which compares the "CN" fields, provide a means to transparently update an organization's name and address. To change this certificate information, an organization acquires a certificate chain that specifies the updated information, but matches against one of these earlier checks.

It is common for an organization to use multiple, unrelated domain names. The final check in the matching algorithm enables sharing of history across all the hostnames used by an organization.

No support for non-SSL data exchange

The editor bar supports safe entry of text strings by the user into a web site with which a continuous relationship has been established. The user can expect this continuity to be securely enforced and the transmissions protected from eavesdropping and tampering. Currently, these properties can only be supported on the web through the use of SSL. The editor bar MUST NOT be enabled for exchanges that are not protected by SSL. If the user hits the editor bar attention key when visiting a site not protected by SSL, the user agent MUST present a message meaning:

This web page does not support secure information exchange, and so the editor bar cannot be used here. Information entered into this web page may be seen, or tampered with, by others on this network. Click here to see if the web site supports a secure version of this web page.

Selecting the provided option navigates the browser to a URL constructed by changing the current page's URL scheme to a corresponding one that uses SSL. For example, an http: URL is converted to an https: URL.

Creating a new relationship

When visiting a web site, the user summons the editor bar via an attention key, or a toolbar button, or in some other way. In response to this request, the editor bar searches its history database for an entry corresponding to the current web site, using the algorithm specified above. If no match is found, the text entry tool MUST NOT be enabled. Instead, the user agent MUST present a message meaning:

If the user selects the first option, a list of hyperlinks to web sites in the editor bar's history database MUST be provided.

If the user selects the second option, the user agent MUST present a message meaning:

The information in double quotes is information summarized from the web site's certificate.

If the user selects the first option, the user agent MUST navigate to the user's preferred search engine.

If the user selects the second option, the user agent MUST search the database of existing relationships to find any name similar to the newly chosen one. If any matches are found, the user is notified of the collisions and given the opportunity to instead navigate to the corresponding web site. If no matches are found, the user agent updates its database of stored relationships and enables the text entry tool.

All of these messages SHOULD use full-screen rendering which obscures the current web page.

Reliable text

To defend against web site impersonation, the editor bar is designed to only display text strings provided by the user, or statically provided by the user agent software. Implementations MUST NOT display a text string, or graphic, from any other source within the editor bar user interface. The quoted text in the bootstrap message, the part of the message after "belongs to", MUST be distinguished from the rest of the static text. If the described certificate chain was not issued by one of the user-agent's installed and trusted certificate authorities, the message MUST NOT quote any information from the certificate, instead presenting a message meaning: "This web site's credentials are unrecognized". The same two user actions are still offered by the rest of the message.

The name chosen by the user at the end of the bootstrap interaction, called a petname, MUST be the only identifier used by the editor bar user interface to refer to the named site. Each hyperlink in the list provided when the user selects the first option in the first message of the bootstrap interaction MUST use the petname as the hypertext. This list MUST also be accessible to the user via a "Contacts" option. The petname for the current web site MUST also be presented alongside the text entry tool. The user agent MUST provide a means for the user to update the petname used for a web site.

Selection of a text string

The text entry tool supports user entry of a new text string, or auto-completion of a previously entered text string. The editor MUST provide an indication of which of the two actions is being taken. The text field MUST NOT provide auto-completion of stored editor bar text strings that have not been previously submitted to the currently displayed web site.

The text entry tool history menu supports user selection of a previously entered text string. The menu MUST indicate whether or not an offered selection has been previously submitted to the currently displayed web site. Further, the user action to select a text string previously submitted to the current site MUST be different from that to select a text string previously submitted to some other site. For example, text strings previously submitted to the current site could be displayed in a main menu and other text strings displayed in a sub menu. Consequently, the user would have to click more than once to select a string not previously submitted to the current site, but only once for a string that has been previously submitted.

Both of these selection mechanisms purposely require explicit action by the user. Transmission of a text string in a particular request represents user consent for use of that text string for the purpose of that request. The user agent MUST NOT subvert this consent by auto-filling form fields with information taken from the editor bar history. Information MUST only be transferred from the history database to the web page as a result of an explicit approval action by the user.

The editor bar MUST be the only form filling feature of the user agent. A competing form filling feature would undermine the security features of the interaction created by the editor bar.

On screen masking of a text string

Some text strings, such as some passwords, are of such high value that displaying them within the user agent, where they may be seen by an onlooker, is too great a risk. This sub-section specifies a mechanism for marking a text string as one which should not be displayed by the user agent.

The text entry tool history menu MUST provide a means for the user to mark a text string as one which is not to be displayed on screen. Invoking this command prompts the user for a "display name". Wherever a text string would be displayed by the editor bar, the provided display name MUST be shown in its place, as well as an indication that the displayed text is a display name, rather than an actual text string. The auto-completion feature of the text entry tool MUST match keystrokes against the display name, instead of the named text string. Whatever way a display name is selected, the named text string MUST be form filled, not the display name text.

Editing the stored history

Each edit of the editor bar history MUST be explicitly made by the user. In particular, a visited web site MUST NOT be able to add, delete, modify or read the editor bar history. A visited web site MUST NOT be able to receive keystrokes sent to the editor bar by the user.

Some identifiers change over time. For example, a credit card number may change when the card is re-issued. The editor bar SHOULD provide a means to delete a text string. Using this feature, the user can reduce interface clutter created by a text string that is no longer in use.

Under some circumstances, a relationship between the editor bar and a site may need to be terminated. The editor bar MUST provide a means for a user to mark a site as one which will no longer be recognized. When this command is invoked, the editor bar MUST behave as if the relationship never existed, for all scenarios specified by this specification.

Picture-in-picture defense

Many graphical user agents are vulnerable to picture-in-picture attacks. In these user agents, the editor 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.

Detecting a possible Man-In-The-Middle attack

If the user navigates to a web site by selecting a hyperlink provided by the Contacts button in the editor bar and the site presents a certificate chain that can not be matched to one of its previously stored certificate chains, the user agent MUST display a message meaning:

This web site is presenting credentials which cannot be securely matched to those provided in the past. You should not continue with your current task until this error has been corrected. Click here to report this error to the web site's administrator.

Selecting the provided option SHOULD send a notification to an alert service of the user agent's choosing.

Security Considerations

Secure storage

Like the password managers in today's user agents, the editor bar stores information whose confidentiality must be protected. Implementors should use secure storage techniques that ensure the editor bar's database is only accessed by the user. Specifying appropriate storage techniques is beyond the scope of this recommendation.