LG-319 Record password strength stats

[jmhooper]

Why: So that we can measure how our password policies are affecting
the stength of passwords people are creating

How: We do not want the password metrics to be associated with the
user records, so we create a new record, named PasswordMetric which
captures the name of the metric we are calculating, value (e.g. the
length of the password), and count (e.g. how many users have a password
of a given length). The code then does an atomic insert any time a user
sets, resets, or changes their password.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated.

[jgsmith-usds]

I'm a little nervous using our database to gather statistics. I'd be a lot more comfortable using a time series database like CloudWatch or Prometheus (just to name a couple).

Using a time series database allows us to roll up metrics in a lot of ways. We can look at changes over time, means, standard deviations, etc., for a time period, or even trigger alerts if trends go in a wrong direction.

If all we want is to get a snapshot of the current distribution of password lengths and strengths, then this will be enough and we won't need a time series database. Once a few million people have had their statistics aggregated, we won't see much change with the next few million.

[jmhooper]

I think the concern with a time series database is that it allows for an association between the password stats and the user records. So, if I can look at the password stats for a particular time, and find the users who signed up during that time, I can drastically reduce the pool of guesses when brute forcing a password.

[jgsmith-usds]

Good point. As long as we don't log database queries when updating, we should be able to avoid that with the database approach.

[jgsmith-usds]

LGTM

[konklone]

Good point. As long as we don't log database queries when updating, we should be able to avoid that with the database approach.

This would be relevant to a different repo/component, but since this is the thread to discuss - did we look at whether these database queries are logged in a way that would allow an attacker to piece the timing together on a per-user record basis?

[jmhooper]

Dug through the logs and it does not look like we're logging queries when when the accounts are setup. We're logging stuff related to requests, but I didn't see a way to tie it back to a user.

[konklone]

@jmhooper Thanks for digging in!