This is a new piece of behavior: we didn't previously have this limit. This is mostly so that we don't send you a trillion SMS messages if you reload the form a bunch of times.

(But: I think attackers can currently CSRF this endpoint. Not the end of the world, but I'll make a note and fix that.)

Now, the token code is always a random digest, and the factor adds any secret properties it wants to the token body.

Before, for TOTP, the code and the secret were the same, but this was just convenient since they happened to be reasonable substitutes for one another.

For SMS, the secret will be the code we texted you ("12345678"). For duo, it will be something like a transaction ID. These don't make good token codes to identify the challenge you're responding to since they aren't sufficiently random/unpredictable.

This is slightly new. Before, we put totp = true in the form so we could tell if you submitted it or not.

However, we can do this check in a slightly easier way by just testing if we generated or loaded a sync token. If we generated a new one, you can't have a response yet. If we loaded one, you definitely submitted the form so we expect a response.

• "totp" (which meant "did the user submit a guess?") has been simplified into "is new token?", above.
• "totpkey" (which identified the sync token) is now part of the sync token code.

This is new. We didn't revoke the tokens before since it's mostly pointless, but at least does something now that we have a limit on outstanding, unexpired sync attempts.