Recovery code reporting & revocation

[di]

What's the problem this feature will solve?
Currently, we don't support disclosure for our 2FA Recovery codes, nor do we support manual revocation by admins.

Describe the solution you'd like

• Admins can manually revoke leaked recovery codes
• Recovery codes have a recognizable pattern
• Recovery codes can be revoked automatically via our secret-reporting API
• Our existing secret-scanning partners support automated reporting of recovery codes

Additional context
Currently, recovery codes have the following format:

r"^[0-9a-fA-F]{16}$"

This is the result of calling secrets.token_hex(8). This is probably too generic for most secret scanning partners as it will likely result in a large number of false positives.

Ideally recovery codes would have a shared prefix like pypi- which our API tokens use, but we should be careful not to make these codes easily confusable with API tokens.

[di]

Also, this should go without saying, but if we do change the recovery code pattern, we should maintain backwards compatibility with the existing recovery code pattern, just stop generating new codes with it.

[miketheman]

Re: Admins can manually revoke leaked recovery codes

We currently have the ability in Admin UI to wipe recovery codes + 2FA - would that be sufficient to handle this use case?

[di]

The question is whether we know which user owns the recovery codes or not. Since codes are stored as salted hashes in our database, I think we can't actually do the 2nd, 3rd and 4th items here if we are just given a "bare" code.

If we know the user though, a button to wipe the recovery codes is sufficient.