managing contact numbers

Also, managing contact numbers needs to require MFA or evading SMS MFA is trivial. 🐈

Currently, I think attackers can CSRF the MFA enroll endpoint (/mfa/new/?provider=xyz). This could send you an SMS, soon. This is mostly harmless but potentially a little annoying with push factors like SMS/Duo. I'll get a CSRF gate on it.

Also, I think we still have an issue with rate limiting where:

So I don't forget about it: the default settings/ UI is now incorrectly showing Conpherence settings, not date and time settings. Clicking anything works properly.

The need for more UI support on the "MFA Required" flow is making me consider expanding scope here into knocking "Settings" back out to a full-width UI. I think that's not terribly hard. I'm maybe going to start there so it can get more testing as I go through everything else, and I can give up if it's harder than I think.

From D19975, two considerations:

T13227 also needs to happen this week.

The fix for T12921: Link to referenced object in transaction emails (in D19968) is a bit buggy -- the links aren't generating as absolute links with a protocol and domain name. This is likely an easy fix, although I don't expect to get to it tonight.

SMS MFA

since there's a bunch of errata collected here

One issue here is that existing MFA factors now require a concrete Factor object to associate with. To preserve existing behavior, we'd need to create a new one automatically on all installs. This inevitably turns into a little bit of a mess where we have some builtinKey factors and some organic factors. Nothing terrible, but not especially clean.

The other component of that report is that there are 32,768 low-entropy "2048-bit" RSA keys which Debian systems generated until ~2008:

See https://hackerone.com/reports/474897, which suggests that ssh-keygen -l ... ("Show fingerprint of specified public key file.") is probably a pretty good starting point for ssh --is-this-a-valid-public-key:

See PHI500 and T13179. Recent versions of SSH support passing the key fingerprint to the AuthorizedKeysCommand by specifying it like this:

D19935 prepares for multiple MFA provider types.

I expect to make TOTP configuration a concrete object, then pursue Yubikey/U2F (T8787) and Duo (PHI912).

• Also, comment interactions should get a warning when you'll be required to MFA on submit, especially when you don't have MFA on your account.

Also, just so I don't forget:

The bit-strength change above should still happen.

• We still need to key the Image table in Pholio (see D19914) although the right key looks like just <mockPHID>.
• instances/ should get some cleanup for the changes to transactions.

Notes for myself:

One piece of minor mess here -- when you bin/auth recover yourself into a MFA'd account, you can get two MFA prompts: one to upgrade the session, then one to allow you to perform a password reset. Probably, the contextless password reset should only require MFA if you actually submit the form, and should do one-shot MFA, and ideally should carry the challenge tokens from the login and belong to the same workflow, although that's probably impractical.

Bind Challenges to Sessions

This should learn from Auth and support multiple providers of the same type from initial implementation (see T6703).

See D19829 for a followup change: getDetail()/setDetail() should be more-private APIs than they are today, and callers elsewhere (like transaction logic) should use methods like getEncoding(), not getDetail('encoding').