API only: Choosing encryption factors for the seed phrase

Since we leave seed phrase storage up to the client's application, it is important to be strategic with encryption factors for that seed phrase. The encryption factors determine the user experience when setting up the wallet and signing transactions. They also affect the security of the system. Since Wallaby requires the seed phrase to generate private keys in order to sign a transaction, balancing security and accessibility of the seed is essential.

API Implementation

The API implementation lets you choose your own encryption factors and storage location for the seed phrase. To decide what makes the most sense for your use case, you will want to evaluate the level of security you require, compare storage locations, and identify possible encryption factors.

Evaluating Security Requirements

1. What type of assets are you expecting users to hold and what is the expected value of those assets?

If the wallet holder is expected to hold cryptocurrencies or other financial assets, you will require a higher level of security than if the wallet holder is really only expected to hold meme coins.

1. How frequent are wallet operations?

If the wallet holder is going to need frequent access to their funds, you may want to consider prioritizing UX or segregating a portion of the funds.

1. Are the assets replaceable?

If the wallet holder is instructed to only hold assets that can be burnt and reissued such as some NFTs, security tokens, etc. it is probably safe to require a lower level of security.

To ensure you remain non-custodial, your decisions on storage location and encryption factors should leave you unable to independently access the seed phrase. If you would like to discuss your specific use case, please reach out to us at {email}

Choosing a storage location

When choosing a storage location, you will want to consider the context of the embedded wallet. Are you implementing it within a mobile app, a backend system, a desktop app, a website, or somewhere else? Does it need to be accessible from multiple places?

Device Storage

The benefits of this storage location are that it provides one of the highest levels of security without dedicated hardware or a third party. A malicious actor would need access to the device itself in order to steal the seed. Additionally, the wallet holder is not dependent on a provider and the availability of their services.

The downsides to storing the seed phrase on the user's device means you may need to come up with a way to sync the wallet across devices and uniquely handle implementation on each device.

Cloud Storage

The benefits of cloud storage is it enables you to easily sync the wallet across devices and reduces the potential of loss.

The downside is that the wallet holder is then required to utilize a cloud provider something they may be unfamiliar with and that may be disruptive to their UX. Additionally, a malicious actor only needs access to the cloud storage provider in order to steal the seed phrase.

Application Storage

The benefits of application storage is it is the easiest to implement and every application has access to some type of local storage.

The downside is that application data can easily be cleared unintentionally making it susceptible to loss. Additionally, security holes in the application open up vulnerabilities.

Other

You may be interested in other options. For example, third party storage via a hardware provider or a partnership. Perhaps you're interested in the possibility of not storing the seed phrase and recovering it as needed using our beta product Seed Phrase Recovery (Beta). Lesser known options should be thoroughly analyzed.

Choosing encryption factors

When choosing encryption factors, you will want to consider what systems and associated data you have access to. Additionally, each encryption factor should be evaluated to understand if it truly meets your needs. Remember that if you are freely able to access the seed phrase in its chosen storage location, a malicious actor can as well. Here are some examples:

Something only the user has

Examples of this may include at least one of the following:

1. password only known to the user (not stored)

2. private information such as social security

3. biometric

4. a second user owned device (MFA TOTP)

5. access to second trusted accounts

Something only the device has

1. a device specific auth key

   1. generated via biometric ex. passkey

   2. generated via a custom cryptographic method ex. eth-crypto library

2. a text (generally only for low security requirements)

Something only your system has

1. a wallaby salt value

2. a backend auth token

3. a backend salt value