I feel like there's a word for being kicked out of Hogwarts and having your wizarding powers revoked, but it is not leaping to mind.

Yeah -- I initially kept it for a week, but then I was like "it would be better to make that week configurable since it's kind of weird to hard-code it and there's support to make it configurable...", but that was kind of a bit more code and we'd end up with a mild mess removing it later since the configurable part gets stored in Config. I'd also guess there's a real possibility that we never actually look at this table to debug anything.

Some of the TTL/window stuff is a little funky here, my expectation is that this change more of a "shaped roughly correctly/moving us in the right direction" kind of change than a polished product. D19890 improves things a bit. Changes in this sequence all make life harder for attackers, but until everything is in the actual security model the changes implement may have some weird holes in it.

• Move a related logic change to the next diff.

🍰

D19886 ended up renaming "Hint" to "Error Message" and pushing the instanceof X logic into the abstract base AuthFactor class, using this sorta thing:

Yeah, that's T10769.

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

If you want me to look at something, file a report on Discourse with reproduction steps that I can follow to reproduce the issue. I don't need any other discussion or context. I do need working reproduction steps.

No.

Sorry, yeah, I meant T6703.

The effects of this change are left as an exercise for the reader, but PhabricatorPeopleDisableController, for example, won't let you disable a user that has already been approved.

You could also move the log in Disable if you want. I'm not sure anyone's going to approve or disable a user while creating them (and you can't create via the API today anyway) but I think this implementation allows it and the other one doesn't necessarily.

Looks great to me except for the permissions juggling, try this inline?

🌈

I didn't know about %+, neat.

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