I’m diving into Web3Auth’s Shamir’s Secret Sharing (SSS) implementation with their Plug and Play SDK, but I’ve encountered some confusing behavior that doesn’t align with my understanding of the documentation. Specifically, I’m puzzled about how the Device Share component works in practice.
The Documentation vs. Reality Gap
According to the Web3Auth SSS architecture documentation, when an account is initialized, a device share should be created and stored locally on the device. However, when testing with the PnP SDK demo application, I’m seeing behavior that seems inconsistent with this two-factor approach.
My Specific Questions
1. Device Share Storage Location Where exactly is the device share stored on the local device? The documentation isn’t explicit about the storage mechanism:
Is it stored in browser local storage?
Is it a passkey implementation?
Does it use some other browser storage API?
Is there a specific storage location I should be aware of?
2. Cross-Device Key Reconstruction Mystery Here’s where things get really confusing: When I log in with the same social account (Google, Twitter, etc.) on a completely different device, the UI shows I’m getting the same public address. This suggests the same key pair is being reconstructed successfully.
This behavior contradicts my understanding of how SSS should work. If the device share is truly stored locally, how can the same keys be reconstructed on a new device that shouldn’t have access to the original device share? It appears as though only a single factor (the social login) is being used, not the two factors described in the documentation.
The Core Issue
This leads me to believe that either:
The device share isn’t actually required for key reconstruction in the current implementation
There’s some form of cloud backup/sync happening that isn’t documented
I’m misunderstanding how the two-factor system is supposed to work
How can I properly configure the system to enforce the two-factor authentication as described in the documentation? I want to ensure that users truly need both their social login AND their device share to access their keys.
Thank you for your detailed and thoughtful questions, Jerry! You’ve clearly done your homework, and these are common points of confusion when exploring Web3Auth’s Shamir’s Secret Sharing (SSS) implementation, especially with the Plug and Play (PnP) SDK.
Let me break down your queries and clarify the current behavior:
1. Device Share Storage Location
Where is the device share stored in the Plug and Play SDK?
Browser Environment: For the PnP SDK (especially in web/browser use), the device share is typically stored in the browser’s localStorage. This means it’s tied to the specific browser and device you used during initial account creation.
Not a Passkey by Default: The default Plug and Play SDK does not use passkeys or platform authenticators unless you specifically enable WebAuthn (see WebAuthn Guide).
No Cloud Backup by Default: Unless you implement your own backup mechanism, the device share is not synced or backed up to the cloud in the default PnP SDK flow.
Why do I get the same key on a new device if the device share is local?
Great observation! Here’s what’s happening:
Default PnP Flow: In the default Plug and Play SDK demo and standard configuration, only the social login share is required to reconstruct the key. The device share is generated and stored locally, but it is not required by default for key reconstruction.
Result: This means you can log in from any device with just your social login, and the key is reconstructed using only the social share. This is why you see the same public address across devices.
Why is this the case?
The Plug and Play SDK prioritizes ease of use and user onboarding. By default, it does not enforce strict 2FA (social login + device share) for key reconstruction.
The device share acts more as a backup or for advanced recovery flows, not as a strict second factor unless you explicitly configure it that way.
3. Enforcing Two-Factor Authentication (2FA)
How can I require both the social login and the device share for key reconstruction?
Custom SDK Required: To enforce strict 2FA (requiring both social login and device share), you’ll need to use the Web3Auth Custom SDK, which gives you granular control over share management and reconstruction.
PnP SDK Limitation: The Plug and Play SDK does not currently support enforcing this strict 2FA out of the box. It’s designed for single-factor (social login) flows for better user experience.
WebAuthn Option: If you want to add a second factor (like device biometrics or passkey), you can integrate WebAuthn with the PnP SDK, but this is an enhancement rather than a strict requirement.
If you require strict 2FA (social login + device share), consider migrating to the Custom SDK.
For most dApps prioritizing user onboarding, the PnP SDK’s default behavior (single-factor) is intentional.
If you want to add a second factor via passkeys/biometrics, look into WebAuthn integration.
Let me know if you need help with migration steps or a sample implementation!
If you have code snippets or specific flows you want to enforce, please share them, and I can guide you further.
Let me know if this clears things up or if you have more questions!
Note: This response was generated by an AI bot and may require further verification. The Web3Auth support team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. Web3Auth Developer Office Hours
No
Possible