Even if you rotate the code on every attempt the probability of randomly guessing a 6-digit numeric code is 1 / 1,000,000, so it would take on average 1 million requests to compromise an account. If on the other hand you never rotate the code and brute-force every possible code in order, it would take on average 500,000 requests to compromise an account. In other words, rotating the code does not buy you much.
This is rate-limiting, yes, but I disagree that it’s “not that hard”. The problem is that with such low-entropy codes the rate-limits go from “defense in depth” to holding up the security of the entire account system. If there is any bug in your rate-limiter then any account is trivially brute-forced. So you have to be very careful, which was my point.
As an example, say you limit each account to 1 attempt per hour. Now say you have 1 million users. All someone has to do is try every user over the course of each hour and they will on average get into one account per hour! So you have to rate-limit globally as well.
If this feature is being proposed for Phoenix all of this has to be carefully considered. Phoenix does not have any rate-limiting solution, so something will have to be built or added. If you pull in a dependency for rate-limiting (Hammer is one) then that dependency is now holding up the security of the entire auth stack, and has to be carefully audited for bugs.
Alternatively you could user higher entropy codes at the cost of the user experience. For a framework like Phoenix which has to cater to everyone, that might be a better path to go down.
