Policy Usability Challenge - mapto/sprks GitHub Wiki

This page describes an usability issue growing in complexity that is currently unresolved. It has to do with the main interface of SPRKS - the policy control page.

Context

Currently the way the simulation works is that users can set a combination of policy mechanisms for a combination of 27 contexts. These include three dimensions with three values each:

  • employees
    • executives
    • office workers
    • road workers
  • location
    • office
    • home
    • public location
  • device
    • desktop computer
    • laptop
    • mobile device - smartphone/tablet

Each of these has its specifics which the system derives from Incidents (see https://github.com/mapto/sprks/blob/master/static/incidents/touchscreen_public.json for an example how this is specified).

Obviously this introduces great level of complexity (i.e. manipulation of 27 independent policies) that will most probably be overwhelming to a new user. One possible solution to overcome this is to have users select all contexts initially, and when this appears insufficient, allow for distinction of different contexts.

Part of the proposed solution was to allow for the selection of several policy contexts at the same time (use checkboxes, rather than option/radio buttons). This way any changes get applied to all selected policies.

Policies

A non-expert explanation of policies is provided here:

  • Minimum password length (plen) - Defines the minimum length that the system requires for user passwords. Typically if a user attempts to define a shorter password, the system would reject it and ask for a new one. Possible values are 0 (no lower limit on passwords, which practically allows users to set empty passwords); 6, 8, 10, 12 symbols minimum.
  • Minimum number of password sets (psets) - Defines the minimum number of symbol sets that the system requires for user passwords. Typically systems ask users to define passwords that would have elements from more than one of the following sets: lowercase letters (a-z), uppercase letters (A-Z), numbers (0-9), special symbols (e.g. ,.+-!"`'#). Possible values are anything between 1 and 4 symbol sets required.
  • Matching passwords against dictionaries (pdict) - This is just a yes/no value, i.e. should words from the dictionary be disallowed or not.
  • How often do you require your users to renew their passwords (prenew) - Forcing employees to renew their passwords makes sure that even if someone's password is compromised, the window of opportunity for attackers is limited, thus reducing the probability of a conjunction of opportunities happening that would make greater damage possible. However, forcing users to renew their passwords too frequently takes their time and effort to memorise passwords.
  • Checking new passwords for similarity with old password (phist) - Whenever the system requires users to renew their passwords, it could enforce that the new ones are sufficiently different from old ones. This makes it more difficult to guess the new password if someone knows the old one. A typical way of comparing passwords (a type of strings) is to use any type of measure for string distance.
  • How many wrong password attempts do you allow users (pattempts) - Research conducted in our group shows that allowing more attempts increases chances that valid users remember their forgotten password, thus decreasing support (password recovery) effort. However, allowing for unlimited or huge number of attempts allows for brute-force attacks.
  • How are passwords recovered in your organisation (precovery) - A cheaper, but less safe option is to have an automated process. The more expensive procedure is to have a manned help desk where people that have forgotten their passwords can request the issue of new ones. Involving people in the confirming the identity of the person claiming to have lost their password ensures higher quality and more difficult circumvention.
  • biometric - contains only "bdata", which can be either 1 (corresponding to "fingerprint"), and 2 ("iris-scan")
  • passfaces (more accurately image-based) - contains only "pdata", taking values 1 ("passface"), 2 ("swipe-lock")

The technical implementation is discussed in the Policies page. Policies get applied at the end of the month, but users are still allowed to change them continuously. The effect is that changes get accumulated in memory and applied at the end of the month.

Issues

  1. How can context management be visualized?

  2. What gets visualized when the user selects two distinct contexts, but their policies are totally incompatible? Possible solutions are:

  3. One of the policies - presumably the first one selected. In this way the user does not get a chance to see the other one.

  4. Overlap of both policies - i.e. elements that are common get visualized, for the remaining no option should be selected.

  5. Nothing - just not visualize current selection, and use the form as input, not providing the necessary feedback

  6. other?

  7. What should get visualized when the user returns to a policy? The policy that is currently active or the last changes that were already made.