LG-597 Create WebAuthn Configurations Table

[stevegsa]

Why: We want a table to hold configurations for webauthn as a second factor for users.

How: Create a new webauthn_configurations table with a one to many from users. Store the name (user defined), credential_public_key, and credential_id with each configuration and create an index on user_id

Hi! Before submitting your PR for review, and/or before merging it, please
go through the checklists below. These represent the more critical elements
of our code quality guidelines. The rest of the list can be found in
CONTRIBUTING.md

Controllers

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

Database

• Unsafe migrations are implemented over several PRs and over several
  deploys to avoid production errors. The strong_migrations gem
  will warn you about unsafe migrations and has great step-by-step instructions
  for various scenarios.

• Indexes were added if necessary. This article provides a good overview
  of indexes in Rails.

• Verified that the changes don't affect other apps (such as the dashboard)

• When relevant, a rake task is created to populate the necessary DB columns
  in the various environments right before deploying, taking into account the users
  who might not have interacted with this column yet (such as users who have not
  set a password yet)

• Migrations against existing tables have been tested against a copy of the
  production database. See LG-228 Make migrations safer and more resilient #2127 for an example when a migration caused deployment
  issues. In that case, all the migration did was add a new column and an index to
  the Users table, which might seem innocuous.

Encryption

• The changes are compatible with data that was encrypted with the old code.

Routes

• GET requests are not vulnerable to CSRF attacks (i.e. they don't change
  state or result in destructive behavior).

Session

• 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.

Testing

• Tests added for this feature/bug
• Prefer feature/integration specs over controller specs
• When adding code that reads data, write tests for nil values, empty strings,
  and invalid inputs.

[jgsmith-usds]

Let's wait to finalize this until after the market research on Thursday afternoon. If that holds up other things, then let's get together and look at how various sites manage webauthn settings to make sure we can support the likely UX.

[jgsmith-usds]

I'm not sure if we really need this, but probably not a bad idea. The main reason for adding this to the phone configuration is so we can remember confirmed phones without using them for MFA.

[jgsmith-usds]

Something Jon mentioned the other day that would be good to have is a name for the configuration. I haven't added that to the phone configurations table yet, but plan to "soon."

[jgsmith-usds]

Spill over from another PR.

[jgsmith-usds]

Spillover from another PR.

[jgsmith-usds]

This looks fine. I mentioned the name of the text column in a separate comment mainly because a text column gives us the flexibility we need, but the name might be confusing if we store more than just a public key there.

[jgsmith-usds]

This is fine as a text field. We need to store slightly more than just the public key, so making this a credential field rather than just a public_key field that can store a serialized hash will be generic enough to support the structure as described in https://github.com/cedarcode/webauthn-ruby#authentication

[stevegsa]

What other information would be required besides public key? I believe the credential id is actually the user id.

[stevegsa]

Spoke offline. James confirmed that credential id is in fact not a user id but a sequence of bytes.

[jgsmith-usds]

LGTM