Wallet security
Bitcoin wallets contain sensitive information such as recovery phrases, balances, transaction histories, and more. Therefore, it is crucial to add extra layers of security to keep private data, and access to sensitive functionality, out of bad actors’ hands. Additional protection may also be necessary for users who share devices, such as parents with children.
Proactive support
“Usable security & privacy” has become its own topic because it is not enough to simply implement features, it is just as important that users can easily and effectively use them. A highly effective security setting is of no use if users do not realize it exists. So applications should do their best to guide and inform users to adapt appropriate habits and practices, based on where users are in the usage life cycle and the application use case.
Security & privacy checklists
It can be easy to get overwhelmed by long lists of settings. Checklist screens can abstract away detailed settings and provide simplified feedback and recommendations, based on the users previous choices and the current wallet state.
An example checklist for security settings.
An example checklist for privacy settings.
Users should be able to easily access information about how critical features work.
Reminders & recommendations
As a user’s behavior and application usage change, the current security settings may no longer be appropriate. A life-changing amount of funds for one user may be pocket change for another, so it is hard to know what is appropriate. However, applications can still proactively make recommendations and remind users to review their setup regularly.
Applications may regularly remind users to review their security settings.
In clear situations, strong recommendations can be made to switch to a better security configuration.
Preventing unwanted access
A common practice for wallets is to have a barrier (fingerprint scan, PIN entry, etc.) that must be unlocked to open a wallet application. Creating robust and challenging-to-crack passwords and PIN codes isn’t something that everyone excels at. To decrease the chance of someone’s wallet getting hacked because of poor security decisions, you can implement the following into your design:
Biometrics (touch ID & face ID)
Face ID UI from Wallet UI Kit
One convenient way for users to verify their identity to unlock your wallet app is with biometrics. This could take the form of either touch ID or face ID.
Users of Android and iOS devices are already familiar with these motions. More importantly, using biometrics does not require the user to remember anything, decreasing their chances of getting locked out of their wallet.
Unfortunately, biometrics are not supported on all mobile devices. Hardcore security users may be wary about giving up their biometric information.
Tip: Be transparent
Bitcoin wallet users may feel hesitant about the privacy implications of your product storing touch/face ID information. Be sure your app thoroughly relays how this information is stored.
PIN protection
A PIN is one of the most common and traditional methods for securing a mobile application. This setup requires that users create a 4-6 digit PIN that they must enter when opening their wallet application or viewing sensitive information, such as their recovery phrase.
When choosing a PIN, the user is also informed about how it is used.
PIN entry could be limited to a certain amount of unsuccessful attempts per day.
All devices can support the PIN-based approach, which makes it more accessible. A PIN can also be used to encrypt data within a wallet, making any locally stored information on the device inaccessible. Additionally, some users prefer this type of security measure because they use the same or similar PINs on multiple applications/devices, making it easy to remember.
However, users with poor security practices might create easy-to-guess PINs (such as 1234), which would provide a false sense of security. This design also relies on users to remember their PIN correctly.
Do: Educate on good security practices
During PIN creation, tell your users what a good, secure PIN is (e.g. not their birthday). Recommend against (or even make it impossible) to create a PIN such as 1234 or 1111.
Dummy wallet
The user chooses a second PIN to load the wallet with fake data instead.
There may be situations in which users do not want to show their real balances and transactions, or may be forced to disclose access. Here it can be helpful to allow users to set a second PIN, which loads a wallet with dummy data. The user experience of this wallet should look and feel like the actual wallet, but it should only simulate transactions. For an example, see Blue Wallet.
Blocking critical activity
Wallet limits
To further prevent unwanted spending, wallet limits can be established. These can limit the size of single transactions, or impose daily limits. Limits should be changeable at any time, but they should only apply after a certain amount of time has passed. Alternatively, a dedicated password could be required to change limits instantly. So even if a third-party manages to access the wallet, the pace at which they could steal the funds would be drastically slowed down.
App settings with user options to set limits on transaction size and frequency.
Users are notified when they reach the wallet limits.
Deleting the recovery phrase
A user can choose to delete the recovery phrase from the user-facing interface.
After a user has backed up their recovery phrase, an option to delete it may be useful. This only makes the recovery phrase inaccessible to application users. The app itself continues to store the keys and data it requires to function.
Preventing theft when offline
Lightning wallets need to be online to monitor their payment channels to prevent their counterparties from attempting to steal their bitcoin. Mobile wallets, however, are frequently offline, usually due to a poor connection or the user not having the wallet open on their device.
Most major mobile operating systems do not allow apps open in the background to run tasks, such as monitoring a lightning node. This restriction is intended to improve battery life and prevent apps from acting maliciously in the background.
However, this prevents mobile lightning wallets from being reliable monitors of their payment channels. Malicious actors could take advantage of this and attempt to steal a mobile wallet user’s bitcoin by closing channels with incorrect data.
One technique to reduce this risk is to notify the user when the application has been offline for an extended period. This way, they can open the app and thereby enable it to check their channels. Forced channel closes have a built-in, agreed-upon delay. Send notifications earlier than this delay so that users have time to respond appropriately.
Another technique is to use watchtowers. These are third parties that continuously monitor wallets and punish bad actors who attempt to cheat the wallet they are monitoring. Watchtowers should be provided by a different party than the wallet and payment channels to reduce the risk of collusion.
A sample settings page for the lightning network.
Here, a default watchtower service is chosen.
The user has defined a custom watchtower.
The next section looks at privacy considerations when designing a daily spending wallet.