Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Password Card

(Redirected from Password Cards)

{{#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 Higgins Selector 1.1) could 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

We identified 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 (e.g. M=2 if you have a "work" and "home" account on amazon.com), 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 M un/pw combinations for one website. The user would have N password cards in total.
Per role
One password card per role. Each password card stores multiple username/password sets. For example if a person has two roles "work" and "personal" then they would have two cards. The "work" card would store all of the un/pw pair at websites used for work purposes, and the "personal" card all the un/pw pairs for sites used for personal use. There are cases where both cards have un/pw pair for the same site (e.g. amazon.com) because the person uses amazon.com in both their "work" and "personal" roles/lives. The user would have M password cards in total. 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 Options), 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. Of course, this isn't an issue within the Higgins project as we plan to implement these very enhancements. One concern is that if a user creates a password personal card in a Higgins selector, exports it, and then 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. On the other hand all non-Higgins selectors known 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) 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 HBX

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 site (e.g Amazon.com) that the user wishes to login to. From an Information Card point of view the Password Manager code is the "Relying Party."

Enhancements to the Selector

  • Each variant of the Higgins Selector must be enhanced to support a new "add (un, pw, hostname, formSubmitURL, httpRealm)" API. This API add the new un/pw/form-uri data to an existing password card.
  • Each variant of the Higgins Selector must be enhanced to support "arbitrary schema personal cards".
  • In the "per role" design option that has been chosen the username & password claims are multi-valued, complicating the UI.

Enhancements 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).
  • Support must be added to import/export arrays of pairs or triples as values of personal card claims
  • 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

Required Claim Types

The following required claims are used by the Higgins Password Manager:

The selector must be modified to match claims using only the substring to the left of the "?" character.

Preventing Phishing

  • 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 page (see above) parameter as an index
    • It returns as the value of the password claim a string value from the array of passwords found by using the page parameter as an index

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.
Retrieved from "https://wiki.eclipse.org/index.php?title=Password_Card&oldid=167623"

This page was last modified 12:28, 12 August 2009 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top