0

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?

Bennett
  • 653
  • 3
  • 9

1 Answers1

1

I haven't heard of a name for this, but...

A better way to mitigate this is to have a transaction log, rather than just a pair of slots for old and new values. The company's customer service will be able to see rapid changes to the contact information, and can rollback changes no matter how long the attacker has had control of your account before you found out.

Ghedipunk
  • 5,766
  • 2
  • 23
  • 34
  • That's true, but then how does customer service know it's really you contacting them, as opposed to the attacker again? Some companies like banks will have your SSN as a result of you applying with them, but most won't. And for companies like Hotmail it's not scalable to have "customer service". Is there any reason not to just mitigate it using the approach I described, by just not aging out the "old" value too quickly? – Bennett Jun 21 '19 at 17:50