Amplify-js: Auth.setupTOTP silently disables TOTP if it's currently enabled

[tomquisel]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?

This is an issue with Amplify's Auth module, specifically Auth.setupTOTP.

We have a "Change MFA" button for the case where a user wants to change their TOTP MFA secret and already has MFA enabled. If the user clicks it, the app calls Auth.setupTOTP to show the user the new QR code. The bug occurs if the user cancels the process at this point: their User.PreferredMFASetting as reported by Cognito is still SOFTWARE_TOKEN_MFA, but their MFA is in fact disabled. Future signins (even from different devices / using incognito) will not prompt for an MFA code.

The expected behavior is:

1. Starting but not completing the setup of a new TOTP secret should not silently disable the old TOTP configuration.
2. If TOTP is disabled, there should be some indication (User.PreferredMFASetting should reset to null).

Which versions of Amplify, and which browser / OS are affected by this issue? Did this work in previous versions?

All versions.

[powerful23]

@tomquisel are you using aws-amplify-react for this issue?

[tomquisel]

@powerful23 no, just aws-amplify

[powerful23]

@tomquisel thanks for the quick reply. I am now trying to reproduce this error. Can you provide some code snippets?

[tomquisel]

Sure!

Start with a user that has TOTP MFA enabled.

Run this code for them (to start the TOTP setup process):

      const user = await Auth.currentAuthenticatedUser();
      const secret = await Auth.setupTOTP(user);

Then go signin as that user in a new incognito window.

You'll see that you can signin without entering a TOTP code.

Meanwhile, the code below will show that the user still has TOTP enabled:

  const user = await Auth.currentAuthenticatedUser();
  const userData = await new Promise((resolve, reject) => {
    user.getUserData((err, data) => {
      if (err) {
        reject(err);
      }
      resolve(data);
    });
  });

console.log(userData.PreferredMfaSetting);

[powerful23]

The setupTOTP won't do anything to the preferredMfaSetting. You need to call Auth.setPreferredMFA(user, 'TOTP') to change that. So the logic I think is:

1. when clicking the change MFA button, first call Auth.setPreferredMFA(user, 'TOTP')
2. If the user has already setup the totp, then he will successfully change the mfa method to totp
3. If the user hasn't setup the totp, the function will throw an error, and you can then call setupTOTP
4. If the user finishes the whole verification process, call that Auth.setPreferredMFA(user, 'TOTP') again.
5. If the user drops the process, then you should do nothing about that since this process has been canceled, The mfa setting should remain as before.

[tomquisel]

@powerful23 Thanks for explaining that. What you describe sounds like a flow for:

1. Allowing users with TOTP MFA enabled to sync their MFA preference up to their setting
2. Allowing users who do not have TOTP enabled to enable it

My goal is to allow a user with TOTP enabled to _change_ their TOTP secret without accidentally disabling their TOTP entirely. What flow do you recommend for that?

[powerful23]

@tomquisel I see. I will reproduce that and see how it works in this case. Thanks for you feedback.

[powerful23]

@tomquisel We will work with the Cognito team to solve this issue.

[timwhunt]

The Cognito team does recognize this as an issue. We will fix it, but I cannot provide a timeline.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mjmaix]

I don't think this should be closed @stale

[sammartinez]

This seems to be resolved. @tomquisel can you please confirm thanks!

[andrecadete]

I will assume the issue I'm seeing is related to this and in that case it's not solved at all.

It still silently changes the MFA method when logging in "randomly". My use case:

SOFTWARE_TOKEN_MFA is set as preferred yet sometimes when logging in it send an SMS. Just yesterday I logged in multiple times with SOFTWARE_TOKEN and thought maybe this was something I did wrong before. To my surprise this morning the issue came back. Even though the user already signed in multiple times with the software token and the Cognito user still shows preferred mfa method as software token ("PreferredMfaSetting":"SOFTWARE_TOKEN_MFA"), he will get an SMS challenge and not a software token challenge.

I haven't done tests with having only SMS MFA setup to see if it falls back to no MFA at all. But judging from the description of this issue it seems to be related.. Not sure if it's a cognito pool or an implementation issue, but this causes a lot of hassle to our users and extra costs for us as a company. Plus it looks really bad that we request our customers to setup a Mobile authenticator for "extra security" and then they still get an SMS for logging in.

PS: I'm calling amazon-cognito-identity-js methods directly as I do not wish to integrate anything from amplify but last I saw in your codebase it should have the same behaviour and amazon-cognito-identity-js belongs to the amplify repository.
Also, here's a well described issue from another user with the exact same problem almost 4 months ago.. https://stackoverflow.com/questions/62680539/aws-cognito-software-token-mfa-works-once-then-unexpectedly-reverts-to-sms-mfa

Edit: I just found out why this is happening. I tried forcing a new setUserMfaPreference() call right after signing-in with SMS MFA, so long the user preferred MFA was already set to "SOFTWARE_TOKEN_MFA". To my surprise it returned an error response stating the user does not have any confirmed Software MFA method.
Is it possible that somehow Cognito is randomly removing previously confirmed software token MFA methods? I logged in multiple times with software token in the last few days...

[rosspace]

This seems to be the root cause for issue #7254 - I was able to work around it by switch MFA to SMS, then setting to NOMFA, then I had to be careful to only make one call to setupTOTP() before verifying it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.