Correctly handle site-specific words being removed

[blaseur]

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)

[blaseur]

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

e.g., "steelerspittsburgh"

[blaseur]

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]

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.