If the idea is to stop some sort of massed emailing or posting or whatnot, using TOTP as a requirement to take those actions would slow that down to once every 30 seconds-
if it's a matter of access and authentic access(as Microsoft's 'message' when they lock you out notes<suspicious activity>)) TOTP on actions a user may do, should cut down on the idea that an account is hacked.
An initial idea -
If they are worried about account creation being too fast, I suppose one idea then would be a TOTP client-side program that generates a unique account-generation code, one would need to create an account on a service to begin with- and time limit that from both sides, if the worry is a lot of accounts being generated in too short a time.
This way, one can always kill the client code generator, and reinstall it, but overall that doesn't get around the fact you need that to make a full account on the service, and this would slow down creation from someone while not using phone numbers or other meta-data that would be usable against them from a privacy perspective.
I would also look at how the teams from Signal, etc- are tackling that while reducing meta-data
if the idea is indeed about having some method to track the user in a way you can discover other info about them through subsequent means directly, then that's ...what we'd want to avoid.
> If the idea is to stop some sort of massed emailing or posting or whatnot, using TOTP as a requirement to take those actions would slow that down to once every 30 seconds-
No, it wouldn't.
If the service required a TOTP code every time an account wanted to make a post (which would be absurd), that would prevent each account from posting more than once every 30 seconds. But, even if that were desirable, it could be accomplished much more easily with a server-side rate limit.
A spammer has access to many accounts, and would easily be able to generate a TOTP code for each one of them every 30 seconds. TOTP is not a rate-limiting feature, and provides absolutely no benefits here.
