SECURITY BEST PRACTICES
When using the BitGo API, you will reach a point where you will need to automate certain actions. You will need to create an access token as your method of authentication, as they do not require an OTP for spending and can be locked down to a specific IP address.
Access tokens should have a duration set for no longer than your next production deployment, and should have a similar lifetime spending limit.
We recommend modularizing your access tokens with the principle of least privilege. For example, if you have a function that should read wallet balances, the access token it uses should only have the ‘view’ permission. While for sending bitcoins, the access token it uses should only have the ‘spend’ permission.
Do not hardcode your access tokens, keep them as environment variables.
Wallet passwords are the first line of defense for your wallet, we recommend using a different wallet password then your login password as a best practice. In a best case scenario, a user should not know their wallet password at all, instead they should use a password manager which will randomly generate a very strong password. You can print this password and keep it locked away as a backup.
Wallet policies are a powerful tool you can use as a line of last defense for your wallet if your account has been compromised.
Policies can limit spending per hour, day and transaction. Wallet policies also include the ability to create a whitelist of approved recipient bitcoin addresses. Please note that once a policy has been set and untouched for 48 hours, this policy will be unchangeable without intervention by a BitGo employee.
If a wallet carries a balance and there are more than two “admin” users associated with a Wallet, any policy change will require approval by another administrator before it will take effect (if there are no additional “admin” users, this will not be necessary). It is thus highly recommended to create wallets with at least 2 administrators by performing a wallet share. This way, policy can be effective even if a single user is compromised.