How is security ensured in Plug and Play?

How is security ensured in Plug and Play? Do I understand correctly that if the Web3Auth backend is compromised, an attacker could theoretically command Auth network members to sign any transaction on his behalf?

Hello Alexander!

Thanks for reaching out! It looks like you’re exploring security aspects related to the Plug n Play SDK.

To address your question, the security of the Plug and Play feature is primarily ensured through robust cryptographic protocols and decentralized authentication. Each user’s private key is securely generated and stored, mitigating the risk of unauthorized access. Furthermore, the design ensures that even if the Web3Auth backend were compromised, the attacker would lack access to users’ private keys, which means they wouldn’t be able to command Auth network members to sign transactions on behalf of others.

If you have any specific scenarios or further questions about security, feel free to share! Your understanding of the potential implications is very insightful, and we’re here to help clarify anything you need.

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.

When Google returns a JWT to Web3Auth, your backend interprets it as confirmation that the user has access to their account and can sign transactions. As a result, Web3Auth’s backend can then initiate transaction signing on the user’s behalf. However, this raises a concern: if a hacker gains access to your backend, wouldn’t they be able to sign any transaction for any user holding a valid JWT token? Or am I missing something?

Hey @alekhinalexandr.94, PnP SDK works on 2/3, which means to reconstruct the private key, any user will require at least two shares to access the account. When you create an account on PnP SDK, it uses Google login(for instance) as a first share, and the second share is stored on the device you used to login first time. You can additionally add recovery share which can be authenticator app, social recovery.

When you say Web3Auth backend, it’s not a normal Web2 backend, but a substrate of nodes where we have 9 node run by partners like ENS, Binance, and others. These 9 nodes again have shares of the first share (Google - Social Login Share). Out these 9 nodes, at least 5 have to verify that your JWT is valid, to reconstruct the first share (Social Login Share). These share alone can’t be used to sign transactions, or even access your account.

Since second share is on your device, even if Google/ Web3Auth decides to go rouge they can’t access your account because second share is on your device, and none have access to it. Same goes for the recovery share.

You can read more about our SSS architecture: Web3Auth Shamir Secret Sharing Architecture | Documentation | Web3Auth

Thanks! But if my customer wanted to Sign In from his other deivce (lets say second laptop)…Or even lost first device. How do I can reconstruct private key in this case?

Is it possible to use PnP as Sinle factor? If we understand properly by default it is single factor

That’s where the recovery factor comes into the picture. Users can enable the MFA, and add additional factor. We support passkeys, authenticator, social recovery along with other factors like password, and recovery phrase.

Users when using other device, they can use the recovery factor to access the account and save that device as trusted device. On second time using the same device, they won’t require the recovery factor. All these logic is handle by the SDK so you don’t have to worry about managing anything. You can check the doc how to do MFA settings: https://web3auth.io/docs/sdk/pnp/web/modal/mfa

Explicitly trigger MFA Flow: Using PnP Web Modal SDK | Documentation | Web3Auth

Also, to the second question you can access the same account in Single Factor Auth SDK but then you have to manage few things.

  1. User can’t enable MFA, if MFA is enabled you can’t access the same account in SFA SDK
  2. You can’t use default verifiers, you will have to create Custom Verifiers and also manage the OAuth flow in SFA SDK.

Can you please elaborate this:

You can’t use default verifiers, you will have to create Custom Verifiers and also manage the OAuth flow in SFA SDK.

You can checkout the docs: https://web3auth.io/docs/sdk/sfa/sfa-js/authentication

You can checkout our quick-start as well: Integration Builder | Web3Auth

In the quick-start we manage the Auth flow using the Firebase, get the idToken from Firebase upon successful login, and trigger login with Web3Auth using connect method.

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