Building secure digital payment solutions is a challenge when it comes to balancing between convenience and security. How can we build secure digital wallets that meet the needs of fintech users and effectively protect their assets?
- Intro
- Security paradox
- Balancing convenience and security in digital wallets
- Digital payment security: Key risks and threats
- Addressing digital wallet security issues
- Targeting specific risks relevant to digital wallets
- Security failures in digital wallets
- Conclusions and lessons learnt
This blogpost is a part of the “Digital wallet security guides”: Read the articles Crypto wallets security as seen by security engineers, Exploring security vulnerabilities in NFC digital wallets, How to prevent digital wallet fraud.
1. Intro #
Security is often treated as a checklist of features to be implemented, without fully considering the unique risks that digital payment solutions face. This can lead to insecure applications, even if all of the checklist items are checked off.
In this article, we will try to look from a security engineer’s perspective on how to tailor security efforts to your digital wallet applications, your assets, and your users’ best interests. If, of course, this is what you’re after.
2. Security paradox of digital payment solutions #
Being a bank in a pocket, every digital wallet is a convenient tool for accessing accounts and making payments, claiming and sometimes aiming to protect the assets tied to the cryptographic keys, secrets or user identity.
From an aspirational perspective, digital payment solutions should devote enough effort to security. These efforts should focus on protecting user assets and sensitive data by identifying weak points and proactively mitigating potential threats.
Prioritising pragmatic security efforts should contribute to creating reliable platforms, reinforcing the integrity of financial transactions, building user trust and loyalty, and greatly enhancing a company’s reputation.
From a practical perspective, for a startup or a quickly growing application, security is often seen as a distraction, a delay in the process of creation of new features, and a sort of technological debt that is easy to afford.
There’s a popular misconception that building secure-by-design digital wallets can take more time and iterations, slowing down feature releases and product growth. This sometimes turns out to be true, unless the development team has experienced application / product security specialists.
Until it is too late and someone gets hurt.
Popular digital wallets — which prioritised their users’ needs during growth — have friendly interfaces, integrations with additional services, and a large variety of convenience-improving functions. However, it is not guaranteed that they are as secure as they should be.
Incentives of highly competitive markets (for example, cryptocurrency apps are quite hot as a market) are skewed towards building something quickly, and improving security only if you survive long enough. This gets exacerbated in unregulated markets, where there is no authority and regulation to enforce security standards.
Finding a balance between user-friendliness and security is not a small feat: It involves understanding risk exposure and threats, designing application architecture, and implementing a suite of security controls (which are not limited to technical ones).
Striking the right balance between user-friendliness and security.
Explore our approach.
3. Balancing convenience and security in digital wallets #
3.1 Perception of security risk #
Customers and experts perceive the concept of security risk differently.
While technical experts mostly focus on the hazard — the potential harm, the users’ risk concept is based on outrage — the public perception of the risk and the public perception of discomfort that stems from mitigating the risks.
When outrage of potential risk is high, customers overestimate the hazard even when it is low. This leads to a disproportionate allocation of effort in mitigating security risks.
When personal outrage of discomfort associated with security measures (like sloppy UX) is high, customers often migrate to other apps.
Ensuring that users are happy and security efforts do not complicate user experience (and their lives) is essential for security to become a part of a fast-growing product.
3.2 Reduce outrage and build a trustworthy digital wallet #
Developers need to understand how to make a digital wallet app trustworthy to its users. The following steps will reduce potential outrage and contribute to balancing convenience with security in digital wallets:
- Use transparent communication about how user data is collected and used, security plans, ongoing work and incidents to build user trust and confidence in the product. Make your security visible to a reasonable degree.
- Adapt and test security controls for user behaviour in a similar way usability testing is done. This step ensures that security controls are not ambiguous and do not break desired wallet functionality.
- Build compensating security controls – some security controls just don’t work with the way people use mobile wallets, so change them to features that work differently but mitigate similar risks. Don’t want to ruin UX by asking for the application passcode on every start? Make a biometric check before allowing to perform financial transactions.
- User support and education: Provide the users with information about security concerns and best practices (e.g., FAQs, educational resources, how-to-avoid-phishing posts), avoid dark UX patterns, and have responsive customer support when things go right, especially when things go wrong.
- Protect the whole ecosystem: Suppose a wallet allows users to select and connect 3rd party modules or decentralised apps. In that case, it should have the initial and periodic review (which apps/modules to allow) and give a complaint button to users to report questionable modules.
- Involve security engineers with product and financial expertise. It takes special knowledge to efficiently mitigate problems without sacrificing usability. Choose a security leader inside, get on board in-house experts and external consultants, and the results of their work will reinforce all the bullet points above.
- Involve experienced companies to audit your product. Having several additional pairs of eyes to look at your code and issue a public report does improve security to some degree, but it is no substitute for the measures above.
Security is an ongoing effort, not a one-time exercise.
Balancing convenience and security in wallet design requires ongoing evaluation and adaptation. And, as new technologies and threats emerge, a proactive approach to addressing security concerns is necessary.
4. Digital payment security: Key risks and threats #
A digital wallet allows users to store, send and receive digital assets. One way or another, funds are tied to one or several secrets (account private keys and mnemonics), scattered across the user’s brain, application’s memory, (hopefully) encrypted storage on the device and/or in the cloud.
4.1 Risk profile and threat model #
Understanding the risk profile and threat model specificity provides good informational basics on how to protect users’ funds effectively.
Key risks for digital wallets are:
- Loss of financial funds of a single user (unlucky day) or widespread exploits that could result in money loss for many users (tragedy).
- Identity theft and leakage of personal data: User accounts and transactions.
- Reputation loss that may occur as a result of the risks mentioned above or as a result of an independent event (unwanted tweet, for example) leads to funds withdrawal.
Threats differ depending on the platform (mobile or web), and they change significantly between self-custodial and custodial wallets.
- Physical access to the stolen/lost device directly or via stolen smart card.
- Remote access threats via malware, smart contracts and other in-wallet features, via side channels or decentralised apps.
- Private keys access: Depends on where the app stores user private keys and mnemonics. It could be anything from direct breach to insider threat, or even logging the key to a 3rd party service.
- Social engineering and phishing: Users are N1 malware vehicles and could be willing to put their secret phrase to any form that promises free stickers in return.
- Data transmission between application and backend services: Even self-custodial wallets communicate with the backend and could reveal sensitive data.
- Mobile device and mobile OS compromises: Jailbreak, root, attacks like Pegasus, other malware apps that users install.
- Browser and desktop OS compromises: Browser teams’ efforts, attackers continue to find ways to escape sandboxes, bypass defences, and access local storage.
- Vulnerabilities in third-party services and libraries. The third-party libraries included in the code get the same level of access to the application data as the main app. Who said these libraries could be trusted?
A digital wallet application’s security posture depends on a combination of platform security controls, security assurance of the application code, trust in third-party services, user behaviour and many more. Security is determined by the weakest controls, and control inconsistency provides a sufficient attack surface for motivated attackers.
4.2 Custodial & non-custodial, hot & cold, multisig wallets: Security benefits vs threats #
Let’s discuss the most popular applications, including various types of digital wallets. During the early stages of security design, it is necessary to consider not only the general risks and threats listed above but also the specific ones that depend on the wallet type.
Wallets with enhanced security are often perceived as less convenient. The security-first approach makes these wallets less vulnerable to outside threats. At the same time, “less vulnerable” doesn’t mean “100% secure”, especially when we talk about granting users full control. The human factor is the least manageable element of the system, error-prone, and can be manipulated by malicious actors.
Hardware wallet. Photo by Max Saeling on Unsplash
5. Addressing digital payment security issues #
As we found out in the introduction to this post, only a tiny fraction of software products consider security from the very beginning. Security risk will be a natural selection factor unless the market encourages growing faster and providing more user-facing value. Considering the fact that digital payment applications compete on UX, ratings, and user-facing features, security is either an unwanted investment or a risk factor.
Addressing the issues starts with taking active steps to identify security weaknesses, risks and threats that could compromise the security and privacy of users’ data and transactions.
5.1 Clearly define your unique risk and threat profile #
Each digital wallet platform operates within its unique ecosystem: Some wallets preserve privacy and anonymity, others require full Know Your Customer. Some store data one way, some other way, some don’t store it at all. The risks it encounters may differ from the common ones, depending on the technology used, user base, and functionality.
The following steps will guide you through the process of building security for your unique digital wallet:
- Collaborate with stakeholders to ensure that security effort is understood as necessary.
- Identify specific risks for the wallet and your organisation.
- Analyse your architecture to determine where these risks are likely to materialise (when a risk becomes a threat) and where they are unlikely to.
- Develop a targeted security strategy that focuses on the risks with the highest probability and impact.
- Design and build security controls, validate and assess how the wallet handles the edge cases.
- Build your incident response capability: Run scenario drills, ensure you have enough data, and your engineers understand what to do.
- Build user trust, communicate, explain, write guides. Build a communication channel with security researchers.
5.2 Digital wallets: Addressing security risks #
Most typical risks have their typical mitigations when you understand assets you’re protecting. In case with digital wallets, it is some subset of this list:
- User’s keys and mnemonics
- Transaction data during signing
- User’s personal information (names, emails)
- User’s active sessions (for hot custodial wallets)
Scroll back to the Risk profile and threat model section to rewind key risks and threats of digital payment solutions.
Typical mitigations are data-centric security controls, intertwined in a defense-in-depth construction around this data. And it all starts with platform security.
5.3 Platform security #
Digital wallets are built on different platforms: Mobile, website, web extensions, desktop apps, separate hardware devices. Each platform has its own security risks and available security features.
Mobile wallet security starts with the recommendations and requirements outlined in OWASP MASVS and OWASP MASTG. These include secure data storage (don’t store more than the app needs, use hardware-backed encrypted storage), proper cryptography (store mnemonics encrypted and passwords hashed), local authentication bound to biometrics, code obfuscation and minimisation. Even small features like disabling keyboard cache on sensitive fields and blurring the screen when the app goes background are included.
Our internal Mobile Security guidelines for financial applications include 148 requirements.
We should emphasise device trust and remote device attestation, as baseline for any mobile applications with sensitive data. Protection against reverse engineering, detection of rooted/jailbroken device, detection of accessibility features (to mitigate risks of trojans similar to Vultur banking trojan), validation of whether the app is installed from the official market (AppAttest for iOS, PlayIntegrity API for Android) are examples of device trust controls.
Apart from OWASP guidelines, developers should always look for platform-specific recommendations (see our article on React Native application security).
Web wallets and web extension wallets live by different rules, relying on the browser’s sandbox. But browsers are often targeted by 0day malware and memory exploits. Thus, web extension wallets should build encrypted data storage, and minimise the memory footprint of private keys and mnemonics.
Relying on non-cryptographically secure random and outdated ciphers for generating wallet keys and encrypting stored data is another failure for web digital wallets.
Users are susceptible to phishing attacks, tricked into typing their secrets into websites that look like the official ones. Thus, user education about phishing attacks becomes a N3 security task for web digital wallets.
Desktop wallets struggle with secure data storage, as desktop OS use different sandboxing techniques. Stored private keys could be available for superusers and malicious apps.
5.4 API and backend security #
Custodial wallets rely on backend API more heavily, but non-custodial ones might use it as well for supporting service functions.
The typical API / backend service security vectors to look at are: Remote user authentication, user session handling (“logout should revoke session token”), user enumeration (usage of primitive integer user IDs), user data harvesting (“get user email by phone number”), network settings (weak TLS configuration), lack of security headers (CORS, SSRF, CSP and friends), lack of transaction integrity and susceptibility to replay attacks, ability to control wallet behaviour and skip authentication steps.
Backend services require love and care: OS regular security patches and frameworks used, careful request logging and user actions (log enough, but not too much), security monitoring and intrusion detection to stop potential attacks (NGFWs, WAFs). Backup and disaster recovery measures should be in place to restore systems after the incident.
5.5 Supply chain security #
Digital wallets use open-source libraries for cryptography, key derivation, beacon protocol connections, or animations.
Any dependency should be evaluated before your developers add it to the code:
- Is it supported by more than one contributor?
- Does it have open security issues?
- When was the last release? and so on.
Then, a dependency management process kicks in: Automatic tools alert whether the library has security vulnerabilities and requires updates.
Wallets establish connections with online decentralised applications and third-party services (events feed, token prices, transaction history, and so on). These services should be pre-selected and monitored. Wallet developers should stop using a service when it starts behaving suspiciously or maliciously.
Good and problematic dependencies of one typical fintech app.
5.6 Monitoring transactions and addressing security incidents #
Financial security monitoring is based on financial indicators: How many transactions the user generally performs per day? Are all the transactions accounted for? Are there any transactions on suspicious wallet addresses? Are there any “lost” or “blocked” transactions? Limiting the amount of funds available for day-to-day transactions in hot custodial wallets might be a good idea. Monitoring allows detecting anomalies to timely stop potential incidents from happening.
Dealing with incidents — security incidents can occur even when all security practices are followed.
Addressing security incidents requires fast response to analyse the events, contain and mitigate the impact, restore services and protect the company’s reputation. Incident response is a set of measures that include:
- Assessing the scope, impact and nature of the incident.
- Activating incident response team including developers, security engineers, legal representatives, communication specialists.
- Contain the incident immediately by isolating affected systems, disabling compromised accounts, blocking unauthorised access. In worse-case scenarios – stop operations.
- Implementing remediation measures by patching vulnerabilities, enhancing access controls, improving encryption etc.
- Reviewing and improving security practices, conducting security assessments with external auditors.
- Communicating with affected users, stakeholders, and the public to rebuild trust and show the company’s commitment to improving security.
The best time to read all of the above is when you’re not facing an incident and you can test, build routines within your company, ensure that there’s enough data, tools and processes for every step.
5.7 Treating problems systematically: Secure software development lifecycle (SSDLC) #
All suggestions above are, one way or another, extended checklist items we’ve warned you off at the very beginning. Even though they’re filtered through our experience, this is still a very broad field.
To tailor security requirements and efforts specifically to your product, you need to embed security into the development process itself. Based on our experience, it is one of the cheapest and least frustrating ways to build security into applications.
The secure software development life cycle is described in OWASP SSDLC, NIST SSDF, and OWASP SAMM as a collection of repetitive activities for product teams to address security during development, not only before the public release.
The ultimate goal is to address security early, reducing the number of weaknesses and, as a result, vulnerabilities. It requires certain discipline, but achieves 3 outcomes:
- Only specifically valid risks and threats are prioritised
- Mitigations are 100% tailored to application specificity and user experience
- As such, the probability of security incidents decreases, and life becomes predictable to a degree
6. Targeting specific risks relevant to digital wallets #
The financial market requires secure, compliant, and scalable solutions. Thus, data privacy, transaction security, and compliance with regulatory standards are necessary for your digital wallet to be widely adopted in the financial industry.
Digital wallets that operate with fiat money, or allow exchanging cryptocurrency to fiat money, require understanding financial risk models and implementing suitable security controls.
6.1 Key leakage and transaction fraud #
We’ve already discussed cryptographic keys and credentials, which are the most vulnerable parts of the system. Keys, mnemonics, pre-signed transactions, on the other hand, participate in complex data flows before being cleaned from the application’s memory.
The first priority for wallet-specific security measures would be to ensure that keys are not logged (or, worse, are not logged to the server), and that signing processes are not exposed to outside applications in an insecure manner.
These files appear to be harmless logs, however, 000003.log is a browser extension local storage that stores wallet mnemonics. What if we say that this file is accessible to any other application?
6.2 Deanonymisation #
Deanonymisation is the process of associating a user’s identity with their wallet’s public address. Some digital wallets work in anonymous environments, whereas others require identity validation of users.
Deanonymisation could be a significant risk factor for systems that promise anonymity to the users. Even privacy-oriented systems like Zcash or Monero are affected by existing deanonymisation techniques (see An empirical analysis of anonymity in ZCash and A traceability analysis of Monero’s blockchain).
Deanonymisation could be possible if the system collects too many details about the user (IP and MAC addresses, device fingerprints), or uses indirect techniques such as transaction graph analysis or matching user avatars between multiple systems.
From a security perspective, protecting user anonymity requires a lot of effort, not just to build key security controls, but to ensure that side-channel attacks do not reveal too much info.
6.3 Know Your Customer #
In contrast to the previous point, certain wallets require users to go through the Know Your Customer procedure. Many regulatory bodies require KYC procedures to prevent money laundering, terrorism financing, and other illegal financial activities. KYC is used in some countries to help provide financial services to users who can’t visit a physical location to open an account.
Typically this involves uploading a document with a photo (passport) and taking a picture or video of the person so that the system can compare the document to reality.
When a user’s PII is involved, the security stakes rise: Use encryption, working backups, proper backend access control, protection against user enumeration attacks, and many more.
Taking responsibility for user data means more than just saying “Your backend now handles private data.” It’s about understanding that “you’ve made your system the easiest attack surface on your users’ funds.” Think accordingly and build protections.
6.4 Anti-Money Laundering #
AML systems allow monitoring and analysing transaction patterns to detect potentially suspicious behaviours and financial fraud. It includes large transactions, transactions to many new wallets, and transactions during atypical time zones or locations.
AML systems often have real-time alerting and could require the user to perform additional authentication or identity verification.
6.5 Anti-fraud systems #
The anti-fraud system could work together with AML and KYC, or separately. Not all financial fraud is related to money laundering. The internal anti-fraud system could use hundreds of indicators and factors, and be tailored for each specific wallet to support the “normal” user behaviour.
Building the financial anti-fraud system contains several steps: Understanding the user behaviour (what is “typical” and what is not), gathering events, calculating risk scores and making decisions based on them.
Good anti-fraud systems integrate seamlessly into user experience and are visible only to malicious users.
6.6 Regulations and compliance #
Operating with finances requires compliance with the regulatory landscape. Even if you’re not regulated by financial regulators, data privacy laws (GDPR, CCPA) require the protection of users’ personal information anyway. This includes encryption in transit and storage, authentication, backups, as well as the ability for users to remove their data, migrate it to another provider, or assign it to a custodian in case of disaster.
The regulatory landscape for cryptocurrencies is continuously changing, and new regulations are being planned. For example, the Netherlands, require compliance with AMLD5 which means that cryptocurrency exchanges and wallet providers are required to follow AML and KYC procedures, including customer identification and reporting suspicious transactions.
6.7 Building trustworthy digital payment platforms #
It is possible that not addressing security issues may kill the product, but resolving these risks while impairing usability will kill the product. Slowing down the development pace will also harm the product.
So, what should we do? Simply meeting the requirements of application security, M/ASVS L2+R, or other compliance standards is not enough. Neither CSF, SOC, nor even the highly specific MASVS will help.
Balancing hazard vs outrage vs tradeoffs should target a real risk model.
Risk-specific technical solutions are more effective for risk mitigation than the board recommendations like “use awesome cryptography” or “turn on this great SAST”.
For example, a wallet can choose not to store particular data, split authorisation between multiple parties, or “risk-score” transactions before executing them. It makes sense to invest in data privacy for wallets that collect users’ personal data. However, if the wallet does not store this data locally, using hardware-backed encrypted storage might be a later step. Simultaneously, for non-custodial wallets that store wallet mnemonics, complex storage encryption must be the first step.
7. Security failures in digital wallets #
When thinking about “security,” we should focus on the failure causes we want to avoid rather than the security measures we want to incorporate in the product. It is a great temptation to start any security blog post with a “what could go wrong” section to scare people into security, but this was not our point. We expect people who read this far to be interested in making their users’ funds well protected.
Security failures can result in financial loss, compromised user data and serious damage to a company’s reputation. The reasons for failure do not end with the OWASP Top10 but include a wide range of weaknesses and combinations of them. See the Risk profile and threat model section for further information.
After a good portion of practical tips on building secure digital wallets, it’s high time to see what happens when security is not the cornerstone you build your product on. The cases we are going to discuss act like an eye-opener for those who care about user assets and their own reputation. Understanding risks, threats and failure models is essential for building secure digital wallets. Let’s take a broad picture of security failures before investing in security solutions.
7.1 Security incidents with custodial and non-custodial wallets #
Custodial wallet security is dependent not just on the wallet, but also on the security of the centralised wallet backend services (financial gateway, wallet API, and third-party services). On the contrary, non-custodial wallets place the responsibility of securing private keys and assets on the users as well as the wallet application itself.
7.2 Security incidents with banking apps #
Banking apps are vulnerable to data breaches, man-in-the-middle (MITM) attacks, insider threats, exploits of the app and the backend, malware and phishing attacks.
8. Conclusions and lessons learnt #
No matter how good or popular a wallet is, it is only a matter of time before it is broken given sufficient financial motivation for attackers.
Most incidents, listed in the previous section, have one thing in common: The application was not designed with security controls in the first place. Addressing general and specific risks before the first breach, increases the chances of survival, but it can distract from product competition and new feature development.
Often, popular wallets with poor general application security can survive for some time as long as they address key threat vectors. Ultimately, only the strong survive in the long run.
Understanding the trade-offs between security and usability requires special skills and knowledge. We can’t instantly turn your application developers into application security engineers. But we’ve tried our best to share some directions that will help you on your way.
If you’re struggling with digital payment security and building security wallets, you’re not alone, feel free to drop us a line to get some assistance.
This blogpost is a part of the “Digital wallet security guides”: Read the articles Crypto wallets security as seen by security engineers, Exploring security vulnerabilities in NFC digital wallets, How to prevent digital wallet fraud.
