Password encryption adds an extra layer of security to embedded wallets by requiring a password to decrypt the user’s key share. This ensures that even if an attacker gains access to the stored key share, they cannot use it without the password.Documentation Index
Fetch the complete documentation index at: https://docs.dynamic.xyz/docs/llms.txt
Use this file to discover all available pages before exploring further.
How it works
When password encryption is enabled, it specifically protects the client-side key share:- The user’s client key share is encrypted with their password.
- This encrypted share is sent through an encryption proxy which adds a second layer of encryption before storing it on Dynamic’s servers. This ensures the share is double-encrypted and accessible from any device.
- Operations like signing transactions require the password to decrypt this share once per session; after unlocking, the user is not prompted again until the next session.
- The password is never sent to Dynamic; decryption happens entirely client-side.
- No single party (Dynamic, encryption provider) can access the key share alone.
Requiring password for wallets
You can require all wallets to have a password in the Dynamic Dashboard:- Navigate to Embedded Wallets.
- Toggle Require Password to enforce that all wallets must be created with a password.
When Require Password is enabled, a password must be provided when creating a wallet. Attempting to create a wallet without a password will return an error. Once the wallet is created and unlocked, it remains unlocked for the rest of the session—the password is not required for every operation.
Creating a password-protected wallet
Use thecreateWallet method with a password parameter:
Password management
- Users set their own password during wallet creation
- They must enter the password to unlock the wallet
- Important: If the user forgets their password, wallet recovery is not possible without a backup.
Unlocking a wallet
If you use Dynamic’s built-in UI, the user is prompted for their password when needed; you do not need to call unlock yourself. The following applies when you build a custom UI.Custom UI flow
The required flow for custom UI implementations is:- Check wallet state — Call
getWalletRecoveryStateto determine if the wallet is password-encrypted and currently locked. - Unlock if needed — If the wallet is encrypted, collect the password in your own UI and call
unlockWallet. - Proceed with operations — Only after the wallet is unlocked should you perform signing, transactions, or other wallet operations.
Using unlockWallet directly
Before performing operations with a password-protected wallet in your own flow, unlock it using theunlockWallet method.
Operations requiring password
Any operation that changes the underlying key shares requires the password to be provided again, even if the wallet is currently unlocked. These operations include:- Refreshing shares
- Resharing (Cloud backup)
- Delegation
Setting a password on an existing account
If a wallet was created without a password, you can add password protection later usingsetPassword.
Updating the password
Change an existing password usingupdatePassword. This will update the password for all wallets associated with the user account.
Checking wallet lock state
You can check if a wallet is currently locked or ready to use withgetWalletRecoveryState.
Security considerations
- Password strength: Require minimum length and complexity
- No password recovery: If using user-provided passwords, there’s no way to recover a forgotten password without a backup.
- Session-based unlock: Wallets remain unlocked for the session, reducing friction while maintaining security
Related
- Password encryption (React) - React SDK guide
- Password encryption (React Native) - React Native guide
- Password encryption (JavaScript) - Vanilla JS SDK guide