With some services, if an attacker changes the value of a user's contact information (email address, for example), when the user tries to recover their account, they can use either the new or the old value for contact information to do the account recovery, precisely to guard against the attack where the attacker tries to block account recovery by changing the contact information.
The problem is that some services implement this incorrectly, so that if you just change the contact information twice, these values become the values for the "new" and "old" contact information, which means the attacker just has to change the email address twice and now they control both addresses.
It seems the correct implementation would be that when an "old" value has to have a minimum time being the "old" value before it can be "aged out". So if you change your email address from A to B, then the stored values would be: current_value: B old_value: A But then if you immediately change your email address to C, then the values should be: current_value: C old_value: A rather than updating old_value to B. And then if you wait some time period (say, two weeks) so that A can now actually be aged out, then if you change your email address from C to D, then the stored values become: current_value: D old_value: C
Is this a documented attack that has a name? ("double-new" seems inelegant.) Does this seem like the correct mitigation?