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

Difference between revisions of "Password Card"

(Requirements)
(Required Claim Types)
 
(27 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
* 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.
 
* 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.
+
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 ===
 
=== Benefits ===
Line 21: Line 21:
 
=== Metaphor Design Options ===
 
=== 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, and a total of N websites and total of A accounts across all N>30 sites then here are the 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 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 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. 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.
+
;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.
 
After much discussion (see [[Password Card Metaphor Design Options]]), we have decided that the "Per role" option is the best.
Line 34: Line 34:
 
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 [https://informationcard.net/wiki/index.php/Claim_Catalog#Well_Known_Claims here]). Password cards are a special case of what might be called "arbitrary claim personal cards."
 
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 [https://informationcard.net/wiki/index.php/Claim_Catalog#Well_Known_Claims 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.
+
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 ====
 
==== Managed Password Cards ====
Line 56: Line 56:
 
=== Architecture ===
 
=== Architecture ===
 
Implementing Password Cards involves changes to the Higgins Client and Server.  
 
Implementing Password Cards involves changes to the Higgins Client and Server.  
====Enhancements to the Client====
+
====Enhancements to HBX ====
(A) Enhancements to the [[Higgins Browser Extension]] are shown in red here:
+
Enhancements to the [[Higgins Browser Extension]] are shown in red here:
  
 
[[Image:Pw-cards-1.1.103.png]]
 
[[Image: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.  
+
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."
 
* See [[Higgins Password Manager]] - extension to HBX
 
* See [[Higgins Password Manager]] - extension to HBX
  
(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.  
+
====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.
  
(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).
+
====Enhancements to the Server====
 
+
====Changes to the Server====
+
 
The Higgins Server must be enhanced from its current state as follows:
 
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 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
+
* 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).
+
* 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 ===
+
=== Metaphor Design Option Tradeoffs ===
 
* See [[Password Card Metaphor Design Options]]
 
* See [[Password Card Metaphor Design Options]]
  
=== Supported Claims ===
+
=== Required Claim Types ===
  
The claims and values stored on a password card vary based on which variant of [[Higgins Password Manager]]: "Proxy" or "App" is chosen.
+
The following required claims are used by the [[Higgins Password Manager]]:
 +
* claim type = http://schemas.informationcard.net/@ics/username/2009-3: value is a string (e.g. "paul"). Of the multiple usernames stored on the card, only one is returned--the correct username for the formSubmitURL the user is on as defined by the dynamic value (to the right of the "?") of the formSubmitURL claim (see below).
 +
* claim type = http://schemas.informationcard.net/@ics/password/2009-3: value is a string (e.g. "pass"). As above it returns a formSubmitURL-dependent string value from the total stored set.
 +
* claim type = http://eclipse.org/higgins/claims/hostname ? h=<hostname>
 +
* claim type = http://eclipse.org/higgins/claims/formSubmitURL ? url=<url>
 +
* claim type = http://eclipse.org/higgins/claims/httpRealm ? r=<realm>
 +
* claim type = http://eclipse.org/higgins/claims/usernameField ? f=<the name attribute for the username input in a form>
 +
* claim type = http://eclipse.org/higgins/claims/passwordField ? f=<the name attribute for the password input in a form>
  
''Proxy''
+
The selector must be modified to match claims using only the substring to the left of the "?" character.
* 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")
+
 
+
''App''
+
* 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 ===
 
=== 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.
 
* 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 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 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 ''page'' parameter 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 ===
 
=== Security Concerns ===
Line 107: Line 102:
  
 
=== Open Issues ===
 
=== Open Issues ===
What Triggers the fill in the Higgins Password Manager (within HBX). Alternatives:
+
What triggers the fill in the Higgins Password Manager (within HBX). Alternatives:
 
# the user must click in username (or password??) field to trigger fill
 
# the user must click in username (or password??) field to trigger fill
 
# automatic - native password managers automatically fill
 
# automatic - native password managers automatically fill

Latest revision as of 12:28, 12 August 2009

{{#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.

Back to the top