Page MenuHomePhabricator

Stripping MFA configs with `bin/auth strip` should disable, not delete, the factor configurations
Open, LowPublic

Description

See D19976. Currently, bin/auth strip destroys data permanently. It would generally be better to disable configs instead (for auditing, undo, revocation, etc).

There's no technical or product reason that we destroy configs, it was just easier to implement and it's not hugely high-value.

A caveat here: the "Strip MFA" flow in the cluster reaches into the shard database and executes a DELETE ... so that it can execute synchronously. This needs to be made less abrupt if we're moving away from deletes. This isn't too hard, although it may need some UI hinting because it means that the button will change from actually stripping factors to queueing the strip for the daemons, and it may execute an arbitrarily long amount of time later. We may need to give the administrator better feedback about the process.

Event Timeline

Striping should probably "revoke" (disable + can not be re-enabled), vs the user "remove" button becoming a "disable" action.

For some MFA types, like Duo, we may want to give users additional guidance on the disable flow. The Duo Auth API has no "unenroll" action, so guidance would be "remove this token in your Duo application". Likewise for TOTP. Nothing for SMS ("lose this number and don't @ me again").

For now, I'm continuing to allow users to "Remove" the last active factor on their account when security.require-multi-factor-auth is enabled. This will kick them to the MFA enrollment screen.

This flow is fine, and it needs to work since users can also end up there after bin/auth strip. However, it might be nice to either warn the user ("you'll have to add another factor right away") or prevent the action ("add another factor first") in the future.