Best practices for storing additional backup shares

Help - Core-Kit tKey JS SDK
1

Please provide the following details too when asking for help in this category:

  • SDK Version: 7.2.0
  • Verifier Details:
    • Verifier Name:
    • JWKS Endpoint:
    • Sample idToken(JWT)

We are implementing a tkey based flow on react-native.

Share 1 is generated via a custom JWT created in response to an SMS OTP flow powered by Auth0 and Twilio.

The second share is the device share.

Then we generate a backup share and gate it on successful email verification. We store this backup share on our own server.

We are looking to add one more backup share to guard against the user losing access to their device and one of either the sms/email at the same time. We’re loosely thinking to do a 6 digit PIN code.

However our question is can we store this additional backup share on the Auth Network? Or do we need to store it ourselves?

If we have to store it ourselves, we would have access to two shares and the user’s key would become custodial in that way. Ideally we’d be able to store the key on the Auth Network or another third party service in a seamless manner.

is there any general guidance on how to approach this?

Thanks!

2

Did you use the SecurityQuestionsModule for your first backup share? If so, Afaik this module can only store 1 share.

Btw, how did you store the share to the device on reactnative? I can’t seem to get it working.

3

Once you have enough shares to reconstruct a key, you can use tKey.generateNewShare() to generate a new share. For our first backup share, we created the share that way, then stored it on our own server and gate access to it via a JWT proving ownership of an email address.

As for storing it on device, we are using “expo-secure-store” and just storing it using setItemAsync.

Do you know if shares created via something like the SecurityQuestionsModule are stored on the Auth network? We don’t need to store those ourselves?

4

securityQuestions uses user input as a factor.

also btw be sure to be using manualSync mode on the tKey SDK so as to not to get into any atomicity issues when creating your users key

5

How does one use manualSync mode? And when you say atomicity issues…are you referring to potential key collisions?

6

afaik the doc does not say it explicitly but it does look to me that the SecurityQuestionsModule’s share is stored on auth0 network. The thing is the network has several components: torus, cloud, etc. It’s not clear where exactly it is stored.

you still need to store the password for the SecurityQuestionsModule. I store the password on the local device’s secure storage.

7

I did test this myself. Apparently, the share generated by the tKey.genreateNewShare() will override the previous one. You cannot use the previous share anymore. So basically you can only generate 1 effective new share with this api.

8

Hi @antony.halim

  • The securityQuestionModule, as well as other tkey core kit modules, do not use external services (i.e. auth0) for shared storage.
    Basically, the question/answer as well as security question module share is stored in the metadata as a tkeystore, and the tkeystore is only accessible to the corresponding privatekey.

  • The password for the securityquestion is the part that the user needs to remember, but it can be customized by the developer to be stored elsewhere as needed. This may not be the intent of web3auth, so be careful.

  • It is also not true that using Key.genreateNewShare() will prevent you from using the old share. Any share can be used to recover a key, as long as you have proper access to each share.

9

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