GitHub - cupslab/password_meter: This project implements a data-driven password meter. Its effects on password security and usability were evaluated in the following publication: http://www.blaseur.com/papers/CHI17meter.pdf and a demo is available at: https://cups.cs.cmu.edu/meter/ (original) (raw)

This project implements a data-driven password meter. Its effects on password security and usability were evaluated in the following publication: Ur et al. "Design and Evaluation of a Data-Driven Password Meter." In the Proceedings of CHI, 2017. https://dl.acm.org/citation.cfm?id=3026050

The project is written in TypeScript, which transcompiles to JavaScript.

The original implementation of this password meter (v1.0) has been extended to include additional support for minimum-strength and blocklist requirements (v2.0). Password-policy configurations based on these new requirement types were evaluated in the following publication: J. Tan, L. Bauer, N. Christin, and L. F. Cranor. "Practical recommendations for stronger, more usable passwords combining minimum-strength, minimum-length, and blocklist requirements." In the Proceedings of CCS, 2020. https://dl.acm.org/doi/10.1145/3372297.3417882

This project uses the Pwned Passwords API to check for previously leaked passwords.

A JavaScript library (hibp-js has been used in this project, with minor modifications.

An online demo of the meter is available at https://cups.cs.cmu.edu/meter2/

Contact

password-guessability@cs.cmu.edu

Deploying (minimal customization required)

Many potential users of the meter will not need to re-transcompile from TypeScript to JavaScript. Instead, such users can use the code in the /example directory, which contains a ready-to-run environment for the password meter. The primary HTML file is index.html. The password-policy requirements and other meter configuration can be set by editing parameters defined in config_policy_meter.js

We expect that most people who take advantage of the example files will edit two sets of common configurations that are made available in config_policy_meter.js:

  1. "domainSpecificWords" should be updated to contain a list of site-specific words that should count for nothing in the password. We currently provide a small set of examples specific to CMU.
  2. A number of variables (minLogNnGuessNum, length, prohibitKnownLeaked, etc.) define the site's mandated password-composition policy. In the example file, it is set to require a 1c12+NN10 policy that also prohibits known leaked passwords reported by the Pwned Passwords API. The other dimensions are currently set to inactive, but can be enabled by simply editing these variables.

Beyond these configuration decisions, we expect that people who deploy our meter will edit the layout in /example/index.html and /example/config.css

Note that running the meter's code locally on your computer using "file" URLs with browser's default settings will not load the dictionary files (dictionary-*), and as a result no feedback will be given based on the use of dictionary words or common passwords. In contrast, if loaded from a web server (e.g., Apache), these files will be loaded correctly.

Note also that the meter expects all files to be in the same directory as each other.

Building from source

Finally, the neural network that estimates password strength needs to be trained for a site's particular password-composition policy. The parameter files must be provided in the configuration. The example neural network files we provide (/example/tfjs_1c8/*) are trained for a 1class8 policy and may not provide accurate strength estimates for passwords created under different policies.

For more detail on training the neural network, please see https://github.com/cupslab/neural_network_cracking

For more detail on importing a custom TensorFlow model, refer to https://www.tensorflow.org/js/tutorials/conversion/import_saved_model

Dependencies

Our meter depends on several external web-development libraries:

Setup

To set up the meter, define the following global variables for the above dependencies before referencing the PasswordMeter.js file:-

Once a compliant password has been devised, the meter code will call out to a function "continueSubmit" with the password as an argument. The code in example/index.html will currently display a Javascript alert, but can be extended as the interface to further processing.

Details of /example files

We label each file with its intended purpose within the meter: main file; neural network computation; visual layout; dictionary; required external library

Characteristics

We tested and iteratively updated many prioritizations of the feedback we provided users in the standard meter. For each advanced heuristic, if the associated function has feedback relevant to that particular password, it returns a non-empty string for both publicFeedback and sensitiveFeedback. If it does not have feedback, which occurs when that heuristic does not indicate a predictable pattern, it returns the empty string. We traverse the list of functions in descending priority for the first (up to) three pieces of feedback to give the user. If, however, our scoring functions rate the password such that its score fills the bar, we ignore all text feedback and tell the user that his or her password appears strong.

The list of functions that provide feedback, in descending order of priority, includes:

Project Contributors

Felicia Alfieri, Maung Aung, Lujo Bauer, Nicolas Christin, Jessica Colnago, Lorrie Faith Cranor, Henry Dixon, Pardis Emami Naeini, Hana Habib, Noah Johnson, William Melicher, Michael Stroucken, Josh Tan and Blase Ur* at Carnegie Mellon University and (*)the University of Chicago, United States.