Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Password Card

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

As is says on the home page:

  • A long term goal is that [the Higgins] client offer what might be called universal login. This is the ability to log you in to almost any website or app (called a Relying Party (RP)) using a variety of methods including I-Card, OpenID and username/password.

This rest of this page discusses how I-Cards in an enhanced client (i.e. enhancements to the Higgins Browser Extension as well as to the various Higgins Selectors) can be used to login to unmodified un/pw-accepting websites.

Benefits

The basic idea is to enhance the Higgins client to enable it to login to existing, unmodified websites that use username/password authentication (e.g. Amazon.com or BestBuy.com). The client would store the site-specific un/pw data as claims on information cards and leverage the users's selector to manage these cards.

With this enhancement the Higgins client would replace the browser's built-in password manager and offer these advantages:

  • Simplicity: One simple, single metaphor to manage all your login-related information whether un/pw or other kinds of personal and managed i-cards.
  • Clean UI: Unlike with some external password managers, no toolbars are added to the browser, and no other "management" interfaces are required by leveraging and reusing the selector's card management interface and functionality. Other than the selector, the UI is the same as for the browser's native password manager's UI.
  • If standard personal cards are used to store un/pw data these cards can be used as a standard un/pw archive format
  • Multi-Browser: Since selector's card stores are external to the browser, a person with multiple browsers will now have access to all of their passwords on all of their browsers (e.g. IE AND Firefox)
  • Multi-Device: With a synchronizing selector, the user's passwords are distributed and synchronized across multiple computers and devices
  • Security: since few users turn on the optional "master password" protection in their browsers, most user's password data can easily be stolen by malicious browser plugins. With Password Cards the user's data is managed external to the browser and with some Higgins selectors protected by a "master password" that we believe will be used more often than the browser's master password mechanism.

Metaphor Design Options

There are three alternatives to consider in how the card metaphor could be applied. If we assume that the user has a maximum of M accounts at any single website, and a total of N websites and total of A accounts across all N>30 sites then here are the options:

Per account
One password card would store one un/pw for one website. The user would have 1..M password cards for a single website. The user would have A password cards in total.
Per site
One password card would store the user's 1..M un/pw combinations for one website. The user would have N password cards in total.
Per role
One password card per role. One password card would store one SET of N username/password pairs. The user would have at least M password cards in total, though likely less than about 2M. Here the term "role" is use liberally, a mother with two children might decide have only one password card for herself and one additional card each for each of her children.

Password Cards are Personal Cards

Although either a personal or a managed card could be used, the benefits of using a personal card are that with this type of card the claim values are stored in the card XML itself, thus the user could use standard card export/import to both archive these cards and/or to move them between selectors.

Note: when we say "personal" card what we mean is a personal card with a special set of claims (e.g. "username" and "password", not the 14 well known claims listed here). Password cards are a special case of what might be called "arbitrary claim personal cards."

The disadvantage of using a personal card is that doing so requires enhancements to the selector to display these cards correctly as well as to prevent phishing. This isn't an issue within the Higgins project as we plan to implement these very enhancements. Theoretically if a user creates a password personal card in a Higgins selector and imports it into a non-Higgins selector (e.g. CardSpace) they could expose themselves to phishing attacks as these non-Higgins selectors may not support enhancements to prevent phishing. However in practice all non-Higgins selectors know today cannot import arbitrary claim personal cards, so the threat isn't real at present. Furthermore, the expectation is that if/when these other non-Higgins selectors choose to implement arbitrary claim personal cards they will also carefully support (or specifically reject) password personal cards.

Requirements

a) Support these Password Card Use Cases

b) Adhere to these constraints:

  • Add no extra UI on the browser chrome (e.g. a toolbar). Roboform and Google Toolbar require you to click a button on a toolbar.
  • Automatically highlight fields that it can fill (like Google Toolbar, Sxipper). Browsers do not natively do this
  • Implement a superset of the browser's built-in functionality

c) If either the per-account or the per-site metaphor design option is used, the selector must segregate Password Cards from other cards to eliminate clutter. Some Higgins selectors support "categories" which can be used to achieve this.

  • Password Cards cannot be moved to other categories.
  • Cards other than Password Cards cannot be moved to the Password Card category.
  • The Password Card category cannot be deleted or renamed

d) Global On / Off – add a control to disable Password Cards.

  • Default is “on”.
  • If turned off, the Password Cards category is hidden from the UI, but Password Cards are not deleted. (In other words, if a user turns this off then back on, they should not have lost anything.)

Implementation

Architecture

Implementing Password Cards involves changes to the Higgins Client and Server.

Enhancements to the Client

(A) Enhancements to the Higgins Browser Extension are shown in red here: Pw-cards-1.1.103.png As you can see the Higgins Browser Extension component has been enhanced by the addition of a Password Manager. This code acts as a "proxy" for the "real" site (e.g Amazon.com) that the user wishes to login to.

After the user points their browser at a new page and and after the web page has been loaded, the password manager would do the following:

  • If both the browser's native password manager and the Higgins password manager are enabled then disable the native password manager.
  • Parse the page looking for a form containing username and password fields.
  • If such form is found, it invokes the selector with the standard "get digital identity" message to the Higgins Selector Switch for NON-SSL sites:
    • required claim = username
    • required claim = password
    • required claim = domain-root>/<domain-of-RP> <-- this is only needed in some metaphor design options (see below)
    • self-issued issuer
  • If no token is returned (meaning that no un/pw data has been stored in the password cards of the selector) then
    • hook the form submit event
    • after the user submits the form, prompt the user to ask if the use wishes to "remember this password" in the usual manner native to the browser,
    • if the user agrees, then read the username and password from the page and send a "add un/pw" message containing the username, password and RP's domain to the Higgins Selector Switch [note: username and password data are not stored in the Higgins password manager]
  • else [a token is returned], then:
    • hook a click event on the username or password input boxes on the page.
    • after the user clicks, retrieve the username and password from the token and input them into the respective input boxes of the page

(B) Each variant of the Higgins Selector must be enhanced to support the new "add un/pw" message mentioned above. Depending on the metaphor design option (see below) handling this message may dynamically create a new password card in the selector, and/or add the new un/pw/domain data to an existing password card.

(C) Each variant of the Higgins Selector must be enhanced to support "arbitrary schema personal cards". Further, it would probably be good to implement a show/hide button next to the value of the password field. This is simpler for the 'per-account' and 'per-site' metaphor design options and very difficult for in the 'per-role' design option (where there are likely 30+ values present).

Changes to the Server

The Higgins Server must be enhanced from its current state as follows:

  • Support for handling of "arbitrary claim personal cards" including import and export (see "Supported Claim" section below for specifics).
  • If the "per-role" metaphor design option is chosen then support must be added to import/export arrays of pairs or triples as values of personal card claims
  • If the "per-role" design option is chosen then the self-issued IdP/STS must add special support for "indexing" into these claim value arrays (using the RP domain as the index) and returning the indexed value(s).

Metaphor Design Option TRADEOFFS

Per role:

  • Pro: Small number of cards means that selector UI doesn't have to have special facilities (e.g. categories) for dealing with hundreds of cards (approx one per site) [Note: this is a non-issue for some Higgins selectors that have been designed in anticipation of managing perhaps 100 relationship cards].
  • Pro: User can customize background image of small number of cards to provide antiphishing protection (recognizable card wallet). [Then again, this feature is already present on the managed cards in the person's selector]
  • Pro: Fewer data objects (cards) for Higgins server operators to have to manage
  • Con: since "role assignment" data is simply unavailable from legacy password managers, automatic import of a person's passwords and the generation of these password cards is not possible. An interface must be presented and the user must manually sorting their existing un/pw combinations (30+) into a handful or so of per-role password cards.
  • Con: Requires support for a new kind of claim value: an array of string pairs [see Supported Claims section below]
  • Con: Requires special logic be added to the self-issued IdP/STS for processing the username and password claims. [See Preventing Phishing section below]

Per site:

  • Pro: The per-account model is consistent with Higgins R-Cards where we expect the user to have one relationship card per site and potentially 100 cards. Then again, there may be advantage in keeping a separation between the user's profile on Facebook (e.g. as held by a Facebook relationship card)
  • Pro: Supports automatic import of un/pw data from "legacy" password managers (e.g. IE's password manager, or Firefox's)
  • Con: Requires the invention of a way to store in the personal card's XML format a "map" of 1..M un/pw/domain triples as the value of a single claim.

Per account:

  • Pro: a Facebook password card (that only stores your Facebook un/pw) could gracefully be upgraded into a full R-Card that added your profile attributes. [OTOH, if we decide that there's a benefit to keeping your un/pw separate from your profile data then an r-card for Facebook could logically and conceptually be completely separate from a "per role" card that has (among a hundred others, your Facebook un/pw).]
  • Pro: Supports automatic import of un/pw data from "legacy" password managers (e.g. IE's password manager, or Firefox's)
  • Pro: A simple set of single-valued claim values can persist the data within the personal card's XML format

Supported Claims

The claims and values stored on a password card vary by metaphor design option:

Per-role

  • claim type = "username": value is an array of {domain, username} pairs (e.g. domain = "amazon.com", username = "paul")
  • claim type = "password": value is an array of {domain, password} pairs (e.g. domain = "amazon.com", password = "pass")

Per-account and Per-site

  • claim type = "username": value is a string (e.g. "paul")
  • claim type = "password": value is a string (e.g. "pass")
  • claim type = http://schemas.informationcard.net/@ics/domain-root/<domain> where <domain> is the domain of the site (e.g. amazon.com): value is ignored! [Since there's no way for card selection to be based on the value of required (or optional) claims, we have to hack the domain INTO the claim type URI itself]

Preventing Phishing

The approach to preventing phishing varies by which metaphor design option:

Per-role

  • The self-issued IdP/STS of the selector has special logic for array-valued "username" and array-valued "password" claim types.
    • It returns as the value of the username claim a string value from the array of usernames found by using the domain of the RP as an index
    • It returns as the value of the password claim a string value from the array of passwords found by using the domain of the RP as an index

Per-account and Per-site

  • No modifications required. Why? Because the only card(s) that will match are those whose domain-root-based claim URI (see Supported Claims section above) matches the RP's domain with the domain-root prefix prepended.

Open Issues

What Triggers the fill in the Higgins Password Manager (within HBX). Alternatives:

  1. the user must click in username (or password??) field to trigger fill
  2. automatic - native password managers automatically fill

Back to the top