3

Some websites make it easy to enrol multiple TOTP apps at the same time but make it difficult to disable these apps. For instance, the user would have to completely reset the MFA settings instead of just disabling one TOTP app, or the user would have to provide a state-issued ID to have this done by user support.

What type of threat scenario does this address? After all, an attacker who would be able to authenticate as a legitimate user would then be able to change the password and lock the legitimate user out, so what is the difference?

Alex
  • 31
  • 2
  • What are the "some websites"? I don't believe this is for security, but just how they have implemented the TOTP. – Esa Jokinen Jun 01 '20 at 14:28
  • I was thinking of OVH (registrar and cloud service provider) and Amazon (the regular Amazon website, not AWS). – Alex Jun 01 '20 at 23:17

2 Answers2

1

I'm assuming the scenario is that you currently have a password and two or more TOTP apps configured. Login requires password + any one of the TOTP apps. I want to consider separately the scenarios where you can successfully log in, and where you have lost access to all your TOTP apps.

Fully successful login

On a technical level, if the user has successfully responded to all authentication challenges, then they have proved that they are who they say they are, you ought to give them full access to configuration of their account. If it's been a while since they last did the login screen (say, > 5 mins), then you might want to re-challenge them before letting them change their login settings; this is to prevent someone walking up to an open laptop and messing with your login settings so that the attacker can then log in as you from their machine.

Note that in this scenario, adding a new TOTP app that the attacker controls is just as bad as removing authenticators or disabling MFA altogether, so any changes to login settings ought to be treated the same.

You lost your TOTP app

It's going to happen; it's been years since you last logged in and you've changed phones in the meantime, whatever. This is closely related to the I Forgot My Password scenario and this often ends up being the weakest link in an otherwise secure MFA system because this Reset workflow often ends up being single-factor. For example, why would an attacker bother with your password and TOTP app if they can do a "I forgot everything" request and only need to get their hands on the link that gets emailed to you? This is the scenario where a human interaction with Customer Support would make sense.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
0

What type of threat scenario does this address?

If a password dump of ServiceA leaks, and it contains the credentials for a user, and this user have an account at ServiceB protected by 2FA, nobody will be able to authenticate as him, even with the correct password. As password reuse is a common problem with credentials (the vast majority of users have few passwords and use the same passwords on every service).

After all, an attacker who would be able to authenticate as a legitimate user would then be able to change the password and lock the legitimate user out, so what is the difference?

If the account is protected by MFA, an attacker will only be able to authenticate as the user if the MFA token was stolen too. If the attacker have the password but not the MFA, those procedures would help protect the account in the case of a password leak.

If, for example, the legitimate user lose his phone with the MFA token, or his hardware token, but knows the password, he can prove ownership of the account by supplying his ID or another details proving he is the owner, before disabling the 2FA and allowing him to login again.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • By the `What type of threat scenario` I don't believe OP was meaning MFA in general, but disallowing revoking only a specific TOTP instead of them all. – Esa Jokinen Jun 01 '20 at 14:27
  • Indeed, I was trying to find a scenario where the attacker would already have a valid password and a valid TOTP generator (in that case why would you disallow revoking a specific TOTP). But perhaps this restriction just depends on how authentication is implemented on specific websites as you point out. – Alex Jun 01 '20 at 23:51
  • @Alex If the server that contains data that links an account to a specific hash the user was given to enter into a TOTP app, was to get hacked and those specific data stolen, then it is possible for an attacker to have both the password and the TOTP. – Amol Soneji Jun 02 '20 at 04:44
  • @Amol Soneji But if the attacker gets there then what is the pount of preventing them from revoking a TOTP while they can add their own TOTP and change the password? – Alex Jun 02 '20 at 09:56
  • @Alex I was just trying to help you think of a scenario similar to "where the attacker would already have a valid password and a valid TOTP generator". – Amol Soneji Jun 04 '20 at 01:36