Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

I am working on a microservice, which is a Next.js-based application. I am encountering an issue where TOTP-based Multi-Factor Authentication (MFA) is successfully enabled for users in Firebase, but shortly afterward, it is automatically unenrolled. Initially, the TOTP MFA setup worked as expected, and I received an email notification confirming that MFA had been enabled for the account. However, immediately after the email is sent, a request is triggered in the logs labeled as "REVERT_SECOND_FACTOR_ADDITION" which removes the TOTP setup for the user.

Upon reviewing the logs, I noticed that this request aligns precisely with the time the email is received, suggesting a possible connection between the email notification and the automatic unenrollment. Additionally, the logs indicate a google.cloud.identitytoolkit.v1.ResetPassword action is being triggered at the same time.

I couldn't reproduce this issue, as I didn't face it in my private setup. Can anyone help me understand why this automatic unenrollment of MFA is occurring? Is there a specific Firebase configuration or security protocol that might be responsible for reverting the MFA setup? Could this behavior be tied to password resets or any other security mechanisms within Firebase or external sources?

Thank you in advance.

Log Details:

{
  "insertId": "__________",
  "jsonPayload": {
    "serviceName": "identitytoolkit.googleapis.com",
    "requestMetadata": {
      "callerSuppliedUserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6523.4 Safari/537.36,gzip(gfe),gzip(gfe)",
      "callerIp": "20.124.252.33"
    },
    "methodName": "google.cloud.identitytoolkit.v1.AccountManagementService.ResetPassword",
    "@type": "type.googleapis.com/google.cloud.identitytoolkit.logging.RequestLog",
    "response": {
      "requestType": "REVERT_SECOND_FACTOR_ADDITION",
      "email": "_______________",
      "mfaInfo": {
        "displayName": "_____________",
        "enrolledAt": "2024-10-21T21:40:25.556859Z",
        "mfaEnrollmentId": "____________-_",
        "totpInfo": {}
      },
      "@type": "type.googleapis.com/google.cloud.identitytoolkit.v1.ResetPasswordResponse",
      "kind": "identitytoolkit#ResetPasswordResponse"
    },
    "status": {}
  },
  "resource": {
    "type": "identitytoolkit_project",
    "labels": {
      "project_id": "_________________"
    }
  },
  "timestamp": "2024-10-21T21:44:10.582Z",
  "severity": "INFO",
  "logName": "projects/_________________/logs/identitytoolkit.googleapis.com%2Frequests",
  "receiveTimestamp": "2024-10-21T21:44:10.635212563Z"
}
You must be logged in to vote

Replies: 3 comments · 4 replies

Comment options

@saipraneethTLS did you find a fix?
We're running into an issue where it auto-removes TOTP MFA

You must be logged in to vote
0 replies
Comment options

We are supposed to re authenticate the credential, that fix helped us. But, I don't know whether it is the right fix.

You must be logged in to vote
1 reply
@anshulalloan
Comment options

@saipraneethTLS
by re-authenticate you mean, users should setup the multi-factor again by scanning the code (this was not sustainable) or we should turn off the firebase muti-factor feature and then re-configure?

Comment options

@saipraneethTLS
@anshulalloan

We were having this issue. The problem, we found, was that the enrollment email that is sent out gets validated by the email client and automatically triggers the unenroll. In the logs for identitytoolkit_project, you can see a google.cloud.identitytoolkit.v1.AccountManagementService.SetAccountInfo event that overwrites the user's MFA, removing it.

To solve this, we modified the action url in https://console.firebase.google.com/project/[project-id]/authentication/emails to return an intermediary page on our website that then links to the unenrollment link that was previously sent in the email. This prevents the user's email clients from accidentally unenrolling them when validating the link.

You must be logged in to vote
3 replies
@CatalanCabbage
Comment options

Damned outlook scanning. Factored this into verification/enrollment link flows, forgot about unenrollment.

Good catch @JaredEzz, will check it out.

@dbousamra
Comment options

Holllllllyy crap, came across this post after pulling my hair out for an hour. This has been one of the most bizarre findings ever. Thankyou!

@sumitsahoo
Comment options

@JaredEzz We are also encountering the same issue. May I know what exactly you did to solve this? For us it is reverting back for few domains but not all, very strange.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
6 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.