Never received a recovery phrase email, but in your platform, you have a message saying it was sent to the gmail address. Looks like there is a bug on your end and these arent being sent out.
I will check this with our team and get back. There is no bug at our end since the phrase is always sent to the recovery email address provided the user opts for that. If he opts to download the phrase manually and does not make a note of it then that is an issue which we can’t control.
For the user 0x1e7c0d34bcc5A9d95509606808AF5349D6CA93d8 google 25107gcz@gmail.com. The wallet was created on 12 Jan 2023. When the user now logs in the same way, a request for a recovery phrase is prompted, stating that the Recovery Factor was sent to *andi25107@hotmail.com on 14/04/22 at 10:08 (see screenshot).
How is it possible that an email with a recovery phrase was sent 9 months prior to the wallet creation? As you mentioned a 2FA has not been set up yet.
@janvdb I have forwarded your request to our team to check.
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. Are you able to check this in your implementation code?
Hi @vjgee, Ill be joining the call later today. To summarize, these are the issues/questions that we are facing:
Issues - Detail
**Recovery Factor requested but users state email was never received **
All 3 users state that they never received an email. Are you sure this is not a bug? Can you confirm that all users have set up 2FA? Is there a way to trigger this again?
Should be linked to 0x1e7c0d34bcc5a9d95509606808af5349d6ca93d8
15 April 2022: Recovery Factor allegedly sent to andi25107@hotmail.com but never received
As detailed above, how is it possible that an email with a recovery phrase was sent 9 months prior to the wallet creation? As you mentioned, a 2FA has not been set up yet.
Clarify login method for following wallet addresses
4. cedric.forkel@gmx.de logs in:
Has 3 wallets - could you clarify how the sign in method for each one?
0x8552967a489d1c363921f983bb5e9917d6f4e569
0xe49afcaaea8b65a94f01fe4265d2ba7f7e7d4745
Should go to 0x34afb9a6b0c4426fafb7d62da1c635c83fdba9a1
Please discuss further on call as your implementation needs to be checked to get to the root of the problem than verifying the wallet addresses. Also, you users need to remember the login methods they use when they create the wallet.
Hi @vjgee, I have been trying to join the call this morning but it kept showing waiting for host to sign in. Could we please schedule a separate call to discuss the implementation?
@vjgee
“We want to turn off the 2FA for both users who have and who haven’t setup 2FA. We’re using the @toruslabs/torus-embed and we added the mfaLevel: ‘none' to the object which we pass into the torus.init({...})
This helped to disable 2FA for users who haven’t setup 2FA previously. But for users who have set up 2FA - prompting the 2FA remains triggered. Is there a way to turn off the latter?“
U mentioned 2FA isnt set up yet
When the user now logs in, a request for a recovery phrase is prompted, stating that the Recovery Factor was sent to *andi25107@hotmail.com on 14 Apr 2022.
Do you have an idea what happened on 14 Apr 2022? Did he a web3auth account with another app? How is it then possible that a new wallet address would be linked to that account in Jan 2023? Just trying to understand what could have happened in April 2022.