Password Card

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

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.

After much discussion (see Password Card Metaphor Design Tradeoffs, we have decided that the "Per role" option is the best.

Personal Password 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.

Managed Password Cards

Although this wiki page is concerned with Personal Password Cards, there are other use cases where a Managed Password Card is a better solution. We envision that these too will exist.

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:

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 claim is not required if the "per-role" design option is employed
  • 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]
  • depending on the metaphor design option, the UX would vary.
    • In the per-role case the selector would search to see if this RP domain was already in one of your password cards and if it was there, ask if it should be replaced. If the domain wasn't present then it would ask you if you wanted to either (a) add the un/pw to one of your existing password cards or (b) create a new password card.
    • In other design options, a different experience would be designed to support replacement/addition of an old/new un/pw pair
• 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

• See Password Card Metaphor Design Options

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.

Security Concerns

• Attack by rogue browser plugin. The password manager functionality described here would be no less secure that the situation today, and perhaps a tad better. Password data is in the clear in the password manager (in HBX) and it thus readable by a rogue browser plugin (just as such a plugin can trivially read all of a user's passwords (especially since few users enable the "master password" feature) today. The situation might be argued to be slightly better in that if the native password manager is used ALL of the user's passwords can be retrieved in one fell swoop, whereas with the Higgins password manager, the rogue plugin would only get one at a time (as they were used at RP sites).

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

Card Synchronization Issues

When designing the implementation, we must remember that (at least some) Higgins selectors synchronize cards across multiple machines. With personal password cards (although not managed ones!) we must remember to design in the necessary data synchronization logic (e.g. storing modified timestamps on the un/pw/domain triples).

Future Enhancements

• Replace expired password with a strong one; automatically. As Mike McIntosh has been saying for years, it would be really nice if we could go a bit further. If HBX could detect that after trying to login using a un/pw at an RP site that the password had expired. It could automatically take the browser to the change update password page and (and here's the best part) it could automatically generate a new strong password for you.

• Password Autogeneration. A partial step towards the previous enhancement would be if HBX would have a way to autogenerate a really good password for an RP site and let the user choose to use it instead of making one up.