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 a topic of its own 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, as well as the application use case.
It all starts with a well-designed first-use experience that introduces users to the most important security options and sets them up for success. Later, users may want to make their own adjustments, or the application can make appropriate suggestions.
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. Still, applications can proactively make recommendations and remind users to review their setup regularly. This can be based on spaced repetition to encourage good habits, or situationally when user behavior changes. These features can be set up during first use, controls can be put on the security checklist, and should be easily disabled in settings.
A full-screen modal with a specific recommendation.
A more subtle inline reminder that takes users to the security checklist.
Users can enable regular PIN reminders so they don’t forget it.
Here are some starting considerations for designing these behaviors:
- Purpose: Should the user remember their PIN, perform a general security check-up, or adjust their security based on context?
- Trigger event: Has a certain time interval passed (fixed or spaced), a threshold been exceeded, or a certain action been taken (e.g. first deposit)?
- Presentation: From OS notification to dismissable modals and contextual banners, there are various options.
- Etiquette: Do not alarm the user, but be helpful. Don’t bother them unless necessary and not during other sensitive activities (e.g. sending).
Security checklist
It can be easy to get overwhelmed by long lists of settings. A checklist screen can abstract away detailed settings (which are also typically spread across various screens) and provide simplified feedback and recommendations, based on the users previous choices and the current wallet state.
An example checklist for security settings.
In clear situations, strong recommendations can be made to switch to a better security configuration.
Users should be able to easily access information about how critical features work.
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. To decrease the chance of someone’s wallet getting hacked, you can implement the following features into your design.
Biometrics (touch ID & face ID)
Face ID can be a convenient authentication mechanism.
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 (Personal Identification Number) is one of the most common and traditional methods for securing a mobile application. This setup requires users to choose a 4-6 digit number. They must enter it when opening their wallet application, or viewing sensitive information, such as their recovery phrase.
Other application activity can also be secured via PIN entry, like approving high-value transactions, editing contacts, deleting the recovery phrase, and more.
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.
Scrambling numbers can make it harder for bystanders to see what was typed.
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 or a cloud backup, making any stored information inaccessible. If you decide to do this, ensure users understand that their wallet cannot be recovered if they lose their PIN and no other recovery mechanism is implemented.
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 one such as 1234 or 1111.
Alternative methods to PIN protection include passwords (which are harder to crack than PINs), as well as swipe patterns.
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 private keys and data it requires to function. For an example, see Blixt.
Deleting wallet data
Tapping continue should show another modal for a final confirmation.
Whether it is after migrating to a new device, or during an emergency situation, a user may want to delete all wallet data, ensuring that it cannot be easily recovered on the device. Note that this is specific to the device. Data stored in a cloud backup will stay untouched.
Also consider allowing the user to choose a unique PIN to quickly delete wallet data in case of an emergency.
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.