Title

Trusted Browser Component to Capture User Intentions

Goals

This proposal satisfies the following WSC goals:

  1. Relevance of security information
  2. Consistent presentation of security information
  3. User awareness of security information
  4. Reliable presentation of security information

Overview

This proposal provides a usable interface to a mutual authentication protocol implemented in the browser. The protocol itself is out of the scope of the WSC working group, however elements of the interface design may be within scope.

The proposal requires users to login to a "Trusted Browser Component", rather than entering login credentials into forms at trusted websites. The interface is designed to capture users' intentions to login to known websites (even when they are at an unknown or untrusted website). By aggregating this data across many users, a third party can provide early detection of phishing websites, without requiring users to be able to detect or to be aware of attacks.

Assumptions

Based on prior research [1, 2, 3], this proposal makes the following assumptions:

Users:

  1. Users can not be relied upon to remember strong passwords. However, users can reliably recall a small number of low-entropy secrets.
  2. Users can not reliably distinguish security indicators from spoofed copies of those indicators, even when those indicators only appear in a reserved area of the chrome. However, users may be able to distinguish an indicator they have customized themselves, from a spoofed version of that indicator.
  3. Users do not notice the lack of security indicators, so wherever an indicator is used, there must always be an indicator for the untrusted state.
  4. Users can not be relied upon to parse URLs, or to read and understand error messages or warnings.
  5. Users may not be able to reliably distinguish the website they are actually at, however users can reliably communicate where they "think" they are at.

Attackers:

  1. All security indicators will be spoofed by attackers. If the indicators are static or are known, attackers will simply copy the indicator into the content of a webpage. Even if the indicators are customized by users (e.g. petnames, security skins), the attacker may used an educated guess to predict the customized indicator.
  2. Any knowledge the user possesses (e.g. passwords) will be a target of attack, and may be captured by an attacker using social engineering techniques. Authentication should therefore not depend solely on knowledge that is possessed by users.
  3. All legitimate security processes and error conditions will be mimicked by attackers to confuse users.

Attacks:

There are two broad classes of attacks:

  1. Site impersonation attacks that attempt to gain website authentication credentials
  2. Site impersonation attacks which attempt to gain other confidential information

This proposal aims to directly address the first class of attacks. By doing so, the proposal may indirectly ameliorate the second class of attacks.

[The proposed interface in conjunction with the mutual authentication protocol are designed to to resist password phishing, active man-in-the-middle and many types of spyware attacks. Resistance to specific attacks will be listed here once the WSC threat trees are finalized].

Usability Principles

[TBD]

Dependencies

This proposal assumes a protocol enhancement to TLS and the existence of trusted third party.

[to do: reference the Available security information it relies upon.]

Use-cases

[to do: reference the use cases it addresses. This section must provide more detailed description of exactly how the user will interact with the proposed user interface. The details provided in this section must be sufficient to enable lo-fidelity testing of the proposal.]

Expected User Behavior

Setup

  1. The user shares a secret with the Trusted Browser Component. The shared secret may be an image selected by the user, or can be another type of secret (e.g., text or audio) to meet accessibility requirements. The shared secret creates a "trusted path" between the user and the Trusted Browser Component. Examples of user customized website and browser interfaces include [4], [5] and [6].
  2. The first time the user visits a trusted website or wishes to create an account at such a website, he must create an association between the browser and "trusted website"(e.g., the browser may automatically recognize that this is a website that supports this login mechanism, the user may be required to perform an action to make an association, the user may be required to supply an out of band activation code). This step represents a one-time trust decision by the user (usability testing is required to determine if users can accomplish this task). This trust decision can be supported with information supplied by the browser (EV status, user's history with the website, others' history with the website).

Login

  1. To login to a trusted website, the user must first "login to the browser" by providing the username and password to the Trusted Browser Component. The user should only provide his login credentials if the browser presents his shared secret.
  2. While logged into the browser, users can login to trusted websites with a simple gesture, for example, by clicking a button "Login to Bank Name website".
  3. If no association exists between the browser and the website, the browser can not enable the required gesture (e.g., can not display the correct login button). Instead, the browser presents a list of know trust associations, and asks the user to select the website he intends to login to. If the user does not intend to login to any of the sites presented, he may create a new trust association (phishers may attempt to mimic the association process, therefore it must be designed with this in mind).

[to do: Each item should refer back to a step in the "Use-cases" section of the proposal].

Disruption

  1. When not logged in to the browser, there is no disruption to the user browsing behavior. (The browser may detect when the user is at a trusted website that has previously been associated, or at a website that supports this feature).
  2. When logged into the browser, the user can log into trusted websites with a single click of a button. This is intended to displace the login ritual of entering login credentials into forms at trusted websites.
  3. To improve resistance to spoofing attacks, it may be desirable to restrict the browser to visiting only associated trusted websites when the user is logged in to the browser (this is TBD based on usability testing).

References

  1. Why Phishing Works, Dhamija, Tygar and Hearst
  2. The Emperor's New Security Indicators, Schecter, Dhamija, Ozment and Fischer
  3. An Evaluation of Extended Validation and Picture in Picture Phishing Attacks, Jackson, et al.
  4. Dynamic Security Skins, Dhamija and Tygar.

  5. iGoogle (Google ig), http://www.google.com/ig

  6. Personas for Firefox, http://www.puffinlabs.com/personas/personas.html

  7. Requirements for Web Authentication Resistant to Phishing, Sam Hartman http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-03.txt