# Wallet Security and Attack Vectors

The primary purpose of all non-custodial crypto wallets is to store wallets’ secrets and sign transactions. Thus, user authentication and secure data storage are the most important security controls presented in every wallet.

In general, Wallets serve these general purposes:
1- Store blockchain secrets
2- Sign transactions
3- Facilitate communication with the blockchain through dApps

The more features crypto wallets have, the more extensive is their attack surface and the more sophisticated is the threat model.

## Application/ Implementation level

This mostly relates to bad coding practices. bugs that can be exploited to create backdoors or cause the wallet to behave in an unintended way.

Most of the Wallet extension audited by me so far has been implemented using reactjs although some were using Angular (TS). Those frameworks provide a level of security and the community is very active. you can easily find plenty of resources discussing best security practices.

Attack vectors that relates to this category:

XSS, MitM attacks, Remote code execution, misconfigurations, using unsafe functions, improper error reporting or leakage of sensitive information...etc

Linters such as [ESlint](https://eslint.org/ "title") or [SonarJS](https://github.com/SonarSource/SonarJS) can be helpful doing a quick automated scan of known issues. However, this requires a lint-by-line review of the entire codebase.

## Improper and Weak Cryptography

Cryptography provides the intrinsic functionality of custodial wallet. One can argue that, at core, wallet are just calls to a key management function while everything else is there to improve user experience and facilitate complex interaction scenarios.

Cryptographic issues are by far the most common among wallet extensions.

Since I'm not a cryptographer, and in light of the golden rule of cryptography:
> Don't roll your own crypto

I don't suggest my own crypto. Instead, follow advice given by experts.

The general concenses is to use community-proven crypto-libraries like Themis and libsodium.

####Organizations: NIST OWASP
#### LA auditors: AC, Jan, Anna

The most common cryptographic issues seen in previous audits

1- Weak storage scheme for wallets data (very common issue in wallet extension due to its reliance on browser's localstorage)
2- Encrypting multiple fields with the same password. Not supporting password changes.
3- Poor or improper key-derivation choices https://github.com/LeastAuthority/auditor-docs/wiki/Key-Derivation-and-Management
4- Allowing low-entropy user passwords (usually resolved by suggesting zxcvbn)

## Denial of Service

Example of DoS attacks impacting wallet extensions is attacking 3rd party source a wallet relies upon. This can be a bigger concern if the source being used is self managed and lacks documentation and proper setup. if a wallet is using a battle-tested provider then make sure to check related documentations and limitations.

## User Authentication

Aside from the cryptographic aspect of user authentication, sometimes wallet extension lack user related controls. Examples:
1- Password management policy
2- Not authenticating critical actions.
3- using bio-metric authentication without extra steps.
4- lack of protection against brute-force attacks.
4- No support for 2FA and Hardware wallets.
For more information check https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

## Local Data Storage

As a non-custodial wallet needs to store the mnemonics, seed and private keys locally. Extension wallets use localstorage (levelDB) a file-based key-value storage. this means that data stored is written directly on the file-system and any process with enough privilege on the OS can access the data. Localstorage provide no encryption capabilities on its own, therefor developers utilize application-level encryption to guarantee secrecy and integrity of user's data. In some cases, data stored by wallets can be levered by attackers to conduct phishing and social engineering attacks.

#### DATA ENCRYPTION IS A MUST, AND IT SHOULD BE DONE PROPERLY.

Refer to cryptography section.

## Platform/Stack specific Issues

The crypto wallet security largely depends on the security of its platform – web, mobile, desktop – and tight integration of security controls between app and platform. The more platforms the crypto wallet supports, the more related security issues might appear. Keeping the threat model in mind at all times, let’s look into various aspects of mobile platform security.

For example, crypto wallet mobile applications often do not check if the device is trusted: if it is rooted or jailbroken, if it has potentially harmful app or reverse engineering tools installed, etc.

Similarly, wallet extensions rely upon its hosting browser. Although I haven't seen this practices nor did I explicitly recommended it due to not finding a way to validate a browser build programmatically, I think this is a good lead to follow.

## Supply Chain Attacks

Probably the most impactful and most common attack of all [even Apple and Microsoft were victims to such attacks](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610). Dependency management in javascript is usually a hard task. I'll avoid discussing details of this attack and jump directly to LA's most common suggestions.

1- Manual and careful assessment of dependencies and transitive dependencies.
2- pinning dependencies.
3- Utilizing automated tools to audit dependencies (CI/CD).

More on the topic from NIST: https://csrc.nist.gov/publications/detail/sp/800-218/final

Tools:
1- https://github.com/NodeSecure/cli
2- https://github.com/sverweij/dependency-cruiser

## Comminucation With 3rd Party Dependencies
Some questions that should be asked to evaluate calls made to 3rd party providers:

- Are communications with 3rd party provider encrypted. (TLS)
- is it prone to MitM attacks? (TLS)
- is it prone to DDoS attacks?
- Having multiple sources and cross matching might - be a good practice sometimes dependeing on the information fetched.

## dApp Communication

One of such typical wallet features is interaction with third-party decentralized applications dApps
This communication introduces the following threat vectors:

Communication between the wallet and the dApp. Without proper authentication, data-in-transit encryption and authorization of transaction data, the attacker may intercept and modify requests – like changing transaction’s amount or recipient’s address.

To mitigate these threat vectors, recommend using a strong transport encryption between crypto wallets and dApps (TLS 1.3 or specific protocols, like Beacon for Tezos ecosystem), doing a proper session management and mutual authentication, and watching the integration point.

https://zengo.com/badapprove-defi-security/
https://zengo-x.github.io/badapprove/
Text above "borrowed" from: source

## User-error prone UI/UX design

## Anonymization and Privacy