Add a temporary token revoker.
Add a session revoker.
Add an SSH key revoker.
Add a password revoker.
Add a VCS password revoker.

These have been added.

Password hashes are stored on the user object. VCS password hashes are stored in RepositoryVCSPassword. These would probably be better if moved to a central password table with a role column.

VCS and account passwords are now stored in PhabricatorAuthPassword and share much more code.

User objects no longer contain password hashes or salts in object properties, theoretically reducing the risk of this material leaking via stack traces and debugging mechanisms.

Passwords can be removed, but can not be revoked (i.e., forcing users to change passwords). This table should also be able to store revoked passwords.

Passwords can now be revoked so that users may not select the same password again.

When instances are exported from Phacility, we currently do not strip VCS passwords, but should.
When instances are exported from Phacility, we currently do not strip Conduit tokens, but should.
Ideally, this workflow should just use bin/auth revoke to reduce code duplication.

We now strip all this stuff and use bin/auth revoke where it makes sense (pending an actual production test).

Is AuthTemporaryToken->userPHID used by anything?

Yes, LFS uses this. This column name is slightly confusing but since it has a legitimate callsite I'm keeping this pecularity out of scope.

VCS passwords should respect account.minimum-password-length.

All password controllers now use the same validation logic and respect account.minimum-password-length (D18902).

While I'm here, we could add a rate limit to "Change Password" to stop occasional researcher reports about this.

This action limit has been installed (D18906).

When SSH keys are revoked with bin/auth revoke, the email should probably exclude the "your account may have been compromised" warning.

This warning is no longer included in the related mail (D18907).

Write some documentation.

Penned thusly (D18911).

Carve a pathway forward on the legacy digest algorithms.

New VCS and Account passwords are digested in a modern, simple way with HMAC SHA256 and a password-specific salt.

Old passwords are automatically upgraded the next time they are used. This is similar to the existing logic to upgrade hashers if a better hasher becomes available.

Old passwords that are never used can not be automatically upgraded via migration (we can't reverse the hashes). For now, we've versioned them and retained the older digest logic so they'll continue working. We may remove this logic and break these credentials at some point far in the future. If we do, users will need to reset any passwords they haven't used in a year or some similar timeframe.

Broadly, with the minor exception of the legacy digests, I think our password infrastructure no longer has any unusual components or odd technical choices. It was more or less satisfactory before and I think we got all the stuff with any real security impact right, there were just a few weird bits -- like usernames as salt for passwords, so that changing usernames broke passwords -- which are no longer weird.