search

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/
Other
185 stars 40 forks source link

Correctly handle site-specific words being removed #4

Open blaseur opened 7 years ago

blaseur commented 7 years ago

We handle site-specific words (e.g., "pittsburgh" in the demo) by removing them from the password before further scoring the password.

Subsequent heuristics can thus be operating on an empty password, resulting in strange feedback. (Note: to reproduce the example below, set "active: false," in the "forbidPasswords" part of the composition policy in /example/index.html)

screenshot from 2017-05-07 21 47 02

blaseur commented 7 years ago

You can reproduce this bug without turning off the blacklist if you concatenate multiple site-specific words:

e.g., "steelerspittsburgh"

blaseur commented 7 years ago

The cause is that we effectively give "zero credit" for site-specific words by removing them from the password before further evaluating it... which is why steelers22 has length 2 as far as the other parts are concerned

jpgoldberg commented 6 years ago

It's an interesting problem, and I have no pretty idea of how to solve it short of building a site specific NN. ("pretty" and "tenable" are not always the same.)

I wonder what would happen if you replaced site specific words with a string that yields close to zero credit, such as "password" or "123". This isn't a very principled way to deal with the problem, but it at the cost of some accuracy, it might have less perverse side-effects.