Users being prompted to use verification factors, even though they never switched 2FA on

Help - Plug n Play
1

Hi,

We have received reports from several users who are unable to access their web3auth accounts. They are being prompted to use one of the verification factors, even though they have never switched on 2FA. Below is an example:

image
image992×1040 36.6 KB

Details which might be relevant: we are using the default verifier on Legacy Mainnet. So far we haven’t been able to identify shared properties among users with this issue (i.e., country, operating system, browser, use of VPN…)

For clarity I emphasize the gravity of this issue: it is causing users to be unable to access their funds.

I appreciate help in solving this issue.

Pedro.

2

@pedro Thanks for your recent post.

I see you Dapp URL is https://picnicinvestimentos.com/ ?

If you specify mfaLevel as none in @web3auth/no-modal , your users will only get two shares: a social share and a device share. However, if you enable multi-factor authentication (MFA) in the no-modal or modal SDKs, your users will receive these two shares plus an additional backup share.

3

Hey @pedro, could you please share the web3auth initialisation snippet and also any config you send during init?

4

Thanks so much @vjgee and @maharshi for your prompt attention. As you can imagine, we’re quite apprehensive about this issue and I appreciate your support.

We’re using a customized version of the @web3auth/web3auth-wagmi-connector. Below are the configuration parameters for the OpenloginAdapter and Web3AuthNoModal classes:

OpenloginAdapter parameters:

{
  "adapterSettings": {
    "chainNamespace": "eip155",
    "clientId": "...",
    "network": "mainnet",
    "chainId": "0x89",
    "uxMode": "redirect",
    "redirectUrl": "http://.../app/web3auth-post-auth",
    "replaceUrlOnRedirect": true,
    "mfaLevel": "none",
    "uiConfig": {
      "appLogo": "/img/logo/easy-picnic-logo-green.png",
      "appName": "Picnic",
      "defaultLanguage": "pt"
    },
    "whiteLabel": { "defaultLanguage": "pt" },
    "sessionTime": 86400
  },
  "loginSettings": { "mfaLevel": "none" },
  "chainConfig": {
    "chainNamespace": "eip155",
    "chainId": "0x89",
    "rpcTarget": "...",
    "displayName": "Polygon",
    "blockExplorer": "https://polygonscan.com",
    "ticker": "MATIC",
    "tickerName": "MATIC"
  },
  "privateKeyProvider": {
    // ...
  }
}

Web3AuthNoModal parameters

{
  "clientId": "...",
  "chainConfig": {
    "chainNamespace": "eip155",
    "chainId": "0x89",
    "rpcTarget": "...",
    "displayName": "Polygon",
    "blockExplorer": "https://polygonscan.com",
    "ticker": "MATIC",
    "tickerName": "MATIC"
  }
}

Regarding mfaMode, I appreciate the information. My understanding was that this would result in only a single share (social share) being used for authentication. It’s worrisome that some users will depend on their current device to access their accounts. What would the best course of action be in this case?

  1. Is setting mfaLevel to ‘mandatory’ the advisable course of action if our priority is enabling users to regain account access in case they lose their current device?
  2. We have not explicitly set mfaSettings. Does the system default to deviceShareFactor in this case? Would you recommend changing this default?

Once again we really appreciate your help. Looking forward to your guidance.

Pedro

5

Unfortunately, the accounts which can’t be provided a recovery share are lost. Since you said that your user base consist of people with low web3 exposure and low technical know-how. I would urge you to keep MFA as none for now. Or even better would be planning to switch to Single Factor Auth web SDK. As the name suggests, it’s based on single factor of authentication. You can read more about it in our docs.

6

Hi @maharshi , thanks a lot for the reply. I believe a 30-minute call might help clarify some misunderstandings on both sides. Would you be available? I just sent you a direct message on LinkedIn as well.

7

@pury @pedro Could you please share the following details
your client id, verifier and its network and the email address/public address of users encountering this issue. It would be great if you could share these details ASAP.

8

I’ll share via our private chat in linkedin so it won’t become public.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.