diff --git a/src/config/SUMMARY.md.develop b/src/config/SUMMARY.md.develop index 1d27699e..dd9f6fb8 100644 --- a/src/config/SUMMARY.md.develop +++ b/src/config/SUMMARY.md.develop @@ -36,13 +36,18 @@ - [Integration & Mapping to Other Frameworks]() - [Appendices]() - [Wallet Security](./wallet-security/README.md) - - [Cold vs Hot Wallet](./wallet-security/cold-vs-hot-wallet.md) - [Custodial vs Non-Custodial](./wallet-security/custodial-vs-non-custodial.md) - - [Hardware Wallets](./wallet-security/hardware-wallets.md) - - [Signing Schemes](./wallet-security/signing-schemes.md) - - [Software Wallets](./wallet-security/software-wallets.md) - - [Secure Multisig Best Practices](./wallet-security/secure-multisig-best-practices.md) - - [Secure Multisig Signing Process](./wallet-security/secure-multisig-signing-process.md) + - [Cold vs Hot Wallet](./wallet-security/cold-vs-hot-wallet.md) + - [Wallets For Beginners & Small Balances](./wallet-security/for-beginners-&-small-balances.md) + - [Wallets For Intermediates & Medium Funds ](./wallet-security/intermediates-&-medium-funds.md) + - [Multisig Wallets For Advanced Users & High Funds](./wallet-security/secure-multisig-best-practices.md) + - [Account Abstraction Wallets](./wallet-security/account-abstraction.md) + - [Signing & Verification](./wallet-security/signing-verification.md) + - [Verifying Standard Transactions (EOA)](./wallet-security/verifying-standard-transactions.md) + - [Multisig Signing Process](./wallet-security/secure-multisig-signing-process.md) + - [Using EIP-7702](./wallet-security/verifying-7702.md) + - [Private Key & Seed Phrase Management](./wallet-security/private-key-management.md) + - [Tools & Resources](./wallet-security/tools-&-resources.md) - [External Security Reviews](./external-security-reviews/README.md) - [Expectation](./external-security-reviews/expectation.md) - [Preparation](./external-security-reviews/preparation.md) diff --git a/src/config/contributors.json b/src/config/contributors.json index e16d464c..ecae3730 100644 --- a/src/config/contributors.json +++ b/src/config/contributors.json @@ -78,5 +78,16 @@ "description": "Creator and maintainer of the ENS framework", "company": "JustaLab", "website": "https://justalab.co" + }, + "pinalikefruit": { + "name": "Piña", + "avatar": "https://github.com/pinalikefruit.png", + "github": "https://github.com/pinalikefruit", + "twitter": "https://x.com/pinalikefruit", + "features": ["steward"], + "role": "Security Researcher", + "description": "Creator and maintainer of Wallet Security Framework", + "company": "Coinspect", + "website": "https://www.coinspect.com/" } } \ No newline at end of file diff --git a/src/wallet-security/README.md b/src/wallet-security/README.md index d179e728..6452114c 100644 --- a/src/wallet-security/README.md +++ b/src/wallet-security/README.md @@ -1,33 +1,40 @@ --- -tags: - - Engineer/Developer - - Security Specialist +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] --- # Wallet Security +In cryptocurrency, the security of digital assets is directly tied to how control over the funds is protected. This section provides a technical deep-dive into wallet security, covering the range from fundamental concepts to advanced practices for safeguarding assets against theft, loss, and unauthorized access. -Cryptocurrency relies on cryptographic keys to secure transactions and manage ownership of digital assets. Proper wallet security is essential to protect these assets from theft, loss, and unauthorized access. This guide covers the fundamental aspects of wallet security, offering insights into different types of wallets, signing schemes, and best practices to ensure a high level of security. +The goal is to move beyond introductory concepts and provide actionable, technical knowledge for securely managing crypto assets. ## Table of Contents -- [Cold vs Hot Wallet](./cold-vs-hot-wallet.md) - Understanding the differences between cold and hot wallets -- [Custodial vs Non-Custodial](./custodial-vs-non-custodial.md) - Comparing custodial and non-custodial wallet solutions -- [Hardware Wallets](./hardware-wallets.md) - Guide to hardware wallet security and best practices -- [Signing Schemes](./signing-schemes.md) - Overview of different signing schemes and their security implications -- [Software Wallets](./software-wallets.md) - Security considerations for software-based wallet solutions -- [Secure Multisig Best Practices](./secure-multisig-best-practices.md) - Best practices for setting up and managing multisig wallets -- [Secure Multisig Signing Process](./secure-multisig-signing-process.md) - Detailed guide for secure multisig transaction signing - -In this section you can: - -- Learn the differences between cold and hot wallets, their use cases, and how to choose the right one for your needs. -- Understand the pros and cons of custodial and non-custodial wallets, and which type suits your security preferences. -- Explore popular hardware wallets, their characteristics, and the importance of using them for secure key storage. -- Get insights into different signing schemes such as EOAs, Multisig, Smart Contract Wallets, and more, including their use cases and security implications. -- Discover various software wallets, their features, and how they can be used securely to manage cryptocurrency assets. - -Effective wallet security is the cornerstone of cryptocurrency security, including taking physical attacks such as the wrench attack into consideration. +- [Custodial vs Non-Custodial](./custodial-vs-non-custodial.md) - Comparing custodial and non-custodial wallet solutions. +- [Cold vs Hot Wallet](./cold-vs-hot-wallet.md) - Understanding the security trade-offs of online and offline wallets. +- [Wallets For Beginners & Small Balances](./for-beginners-&-small-balances.md) - Recommended setups for users with non-critical funds. +- [Wallets For Intermediates & Medium Funds](./intermediates-&-medium-funds.md) - Security upgrades for users with significant assets. +- [Multisig Wallets For Advanced Users & High Funds](./secure-multisig-best-practices.md) - Best practices for setting up and managing multisig wallets. +- [Account Abstraction Wallets](./account-abstraction.md) - Exploring the security features of smart contract wallets. +- [Signing & Verification](./signing-verification.md) - An overview of secure transaction signing and verification. + - [Verifying Standard Transactions (EOA)](./verifying-standard-transactions.md) - How to safely verify transactions from standard wallets. + - [Multisig Signing Process](./secure-multisig-signing-process.md) - Detailed guide for secure multisig transaction signing. + - [Using EIP-7702](./verifying-7702.md) - Enabling smart contract features for EOAs and mitigating new risks. +- [Private Key & Seed Phrase Management](./private-key-management.md) - Best practices for securing your seed phrase. +- [Tools & Resources](./tools-&-resources.md) - A curated list of security tools and resources. + +In this section you can learn: + +- Explore wallet fundamentals, analyzing the security trade-offs of hot vs. cold wallets and the ownership implications of custodial vs. non-custodial models. +- Receive guidance on choosing the right wallet for your threat model, from basic setups to advanced configurations like Multisignature (Multisig) and Account Abstraction wallets. +- Master transaction verification techniques, from basic smart contract interactions to the advanced verification. +- Implement security best practices for private key and seed phrase management. + +Mastering wallet security is a critical skill for any developer, user, or organization operating in the web3 ecosystem. ![security](https://github.com/security-alliance/frameworks/assets/84518844/12e2cba3-f69e-4fde-85f1-8a235b9808af) diff --git a/src/wallet-security/account-abstraction.md b/src/wallet-security/account-abstraction.md new file mode 100644 index 00000000..61c75562 --- /dev/null +++ b/src/wallet-security/account-abstraction.md @@ -0,0 +1,52 @@ +--- +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +## Account Abstraction Wallets + +### User Profile + +Advanced users, developers, and organizations interested in programmable security, customizable transaction rules, and moving beyond the limitations of standard Externally Owned Accounts (EOAs) to eliminate single points of failure like seed phrase loss. + +### Primary Goal + +To leverage the power of smart contracts at the account level, enabling features like social recovery, gas sponsorship, batch transactions, and flexible security policies that are not possible with an EOA. + +### Core Concept: ERC-4337 + +Account Abstraction (AA) turns a user's account into a smart contract, making it programmable. Instead of being controlled directly by a single private key, the account's logic is defined by its code. This is achieved through **ERC-4337**, a standard that enables AA without requiring changes to the core Ethereum protocol. It introduces a higher-level pseudo-transaction system with several key components: + +* **Smart Contract Account**: The user's wallet itself is a smart contract, containing custom logic for validating transactions. +* **UserOperation**: A data structure that bundles the user's intent, calldata, and signature. This object is sent to a dedicated, alternative mempool. +* **Bundlers**: Specialized nodes that package multiple `UserOperation` objects from the mempool into a single transaction and submit it to the `EntryPoint` contract. +* **EntryPoint**: A singleton smart contract that acts as the central orchestrator. It verifies and executes the bundled `UserOperations`, ensuring that accounts and paymasters have sufficient funds to pay for gas. +* **Paymasters**: Optional smart contracts that can sponsor gas fees on behalf of the user, enabling gasless transactions for the end-user or allowing fees to be paid in ERC-20 tokens. + +### Key Benefits & Features + +* **Enhanced Security**: + * **Social Recovery**: Mitigate the risk of losing a primary key by designating trusted "guardians" (other accounts or devices) who can collectively approve an account recovery. + * **Customizable Policies**: Implement robust security rules directly into the wallet, such as daily spending limits, whitelisting trusted contracts, or requiring multisig confirmation for transactions over a certain value. + +* **Improved User Experience**: + * **Gasless Transactions**: Enjoy a smoother experience where dApps can sponsor gas fees, or pay for transactions using ERC-20 tokens instead of needing the chain's native asset (e.g., ETH). + * **Simplified Interactions**: Perform complex, multi-step actions (like `approve` and `swap`) in a single, atomic transaction, reducing clicks and potential points of failure. + + +### Security Considerations & Best Practices + +* **Smart Contract Risk**: The security of an AA wallet is entirely dependent on the quality and security of its underlying smart contract code. Bugs or vulnerabilities in the account's implementation can lead to a total loss of funds. **Thorough audits of the account logic are non-negotiable.** +* **Guardian Selection and Security**: The strength of the social recovery model depends on the security and independence of the guardians. They should be diverse and not susceptible to a single common threat. +* **EntryPoint Centralization**: The `EntryPoint` contract is a central trust point for the entire ERC-4337 ecosystem. A vulnerability in the official `EntryPoint` could have widespread consequences. Use only the canonical, heavily audited `EntryPoint` contract. +* **Paymaster and Factory Security**: Malicious or poorly coded Paymasters and Factories can introduce DoS vectors or other risks. The ERC-4337 standard includes a reputation system and staking mechanisms to throttle or ban misbehaving entities, but users should only interact with trusted and audited Paymasters. +* **Gas Overhead**: The added logic in a smart contract account means that transactions can be more expensive than those from a standard EOA. This trade-off between features and cost should be considered, though it can be offset by gas sponsorship. +* **Key Revocation**: If the primary signing key is compromised, the recovery process allows you to swap it out for a new one without having to move all assets to a new wallet address. +* **Advanced Guardian Setups**: For enhanced security, guardian roles can be implemented using **Multi-Party Computation (MPC)**. In an MPC-based recovery, guardians hold cryptographic shares that are used collectively to authorize a recovery action. This method allows guardians to produce a valid signature through a distributed computation using their individual shares, without ever reconstructing a single master key on any device. diff --git a/src/wallet-security/cold-vs-hot-wallet.md b/src/wallet-security/cold-vs-hot-wallet.md index 44e6dd28..2e8ecd7b 100644 --- a/src/wallet-security/cold-vs-hot-wallet.md +++ b/src/wallet-security/cold-vs-hot-wallet.md @@ -2,46 +2,65 @@ tags: - Engineer/Developer - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] --- # Cold vs. Hot Wallets +The primary distinction between wallet types is their connectivity to the internet. This factor dictates their security threat model, risk profile, and ideal use cases. ## Cold Wallets ### What Are They? -Cold wallets are offline storage solutions for cryptocurrencies. They are not connected to the internet, which makes them highly secure against online attacks. + +Cold wallets are cryptocurrency wallets that store private keys in an offline environment. By being disconnected from the internet, or "air-gapped," by default, they provide the highest level of security against online attacks like malware and phishing. + +Transactions are signed offline and then broadcast to the network using a connected device, ensuring the private keys are stored on device with minimal connectivity. ### Types of Cold Wallets -- **Hardware Wallets**: Physical devices that store private keys offline. + +- **Hardware Wallets**: Dedicated physical devices that store private keys offline and sign transactions without exposing the keys to a connected internet device. - **Paper Wallets**: Physical printouts or handwritten notes of private keys and QR codes. -- **Air-Gapped Computers**: Computers that are never connected to the internet. +- **Software Wallets on Air-Gapped Devices**: Standard wallet software installed on a device that is permanently disconnected from the internet, used for offline transaction signing. ### Use Cases + - **Long-Term Storage**: Ideal for storing large amounts of cryptocurrency for extended periods. -- **High Security Needs**: Suitable for users who prioritize security over convenience. +- **High-Security Needs**: Essential for individuals securing significant value and operating with a low risk tolerance. ## Hot Wallets ### What Are They? -Hot wallets are online storage solutions for cryptocurrencies. They are connected to the internet, making them more convenient but less secure than cold wallets. + +Hot wallets are actively and consistently connected to the internet. This connectivity makes them highly convenient for daily use but also inherently more vulnerable to online attacks. ### Types of Hot Wallets + +- **Browser Wallets (Extensions)**: Software that integrates directly into a web browser, allowing seamless interaction with dApps. - **Mobile Wallets**: Apps installed on smartphones. -- **Desktop Wallets**: Software installed on computers. -- **Web Wallets**: Online services accessible via web browsers. ### Use Cases -- **Daily Transactions**: Ideal for users who need quick access to their funds for transactions. -- **Small Balances**: Suitable for storing smaller amounts of cryptocurrency that are used regularly. + +- **Daily Transactions & dApp Interaction**: Perfect for users who need quick and frequent access to their funds for interacting with applications. +- **Small Balances**: Suitable for storing smaller, non-critical amounts of cryptocurrency that are used regularly. ## Comparison -| Feature | Cold Wallets | Hot Wallets | -|--------------------|--------------------|-------------------| -| Security | High | Moderate to Low | -| Convenience | Low | High | -| Internet Exposure | None | Constant | -| Use Case | Long-term storage | Daily transactions| +| **Feature** | **Cold Wallets** | **Hot Wallets** | +| :--- | :--- | :--- | +| **Convenience** | Low | High | +| **Use Case** | Long-term storage | Daily transactions | +| **Risk** | Physical loss/damage | Online attacks, malware | + + +## **Key Security Considerations** + +Regardless of the type, non-custodial wallets place the full burden of security on the user: -[^gemini]: https://www.gemini.com/cryptopedia/crypto-wallets-hot-cold \ No newline at end of file +- **Online Vulnerabilities**: If the device they are on (computer or phone) is compromised, your assets can be stolen. +- **Supply Chain Attacks**: Be cautious of both software and hardware integrity. Always download wallet software from official sources and purchase hardware wallets directly from the manufacturer to avoid receiving a tampered device. \ No newline at end of file diff --git a/src/wallet-security/custodial-vs-non-custodial.md b/src/wallet-security/custodial-vs-non-custodial.md index c2fb4bea..fb4a9cec 100644 --- a/src/wallet-security/custodial-vs-non-custodial.md +++ b/src/wallet-security/custodial-vs-non-custodial.md @@ -2,45 +2,59 @@ tags: - Engineer/Developer - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] --- # Custodial vs. Non-Custodial Wallets +The distinction between custodial and non-custodial wallets centers on who controls the private keys. This control directly impacts ownership, security responsibility, and the ability to interact with the web3 ecosystem. ## Custodial Wallets ### What Are They? -Custodial wallets are managed by a third party, such as an exchange or a wallet service provider. The third party holds and manages the private keys on behalf of the user. + +Custodial wallets are managed by a third party, such as a centralized exchange (CEX) or a dedicated wallet service provider. In this model, the third party holds and manages the private keys on behalf of the user. ### Characteristics -- **Managed Private Keys**: The third party has control over the private keys. -- **Recovery Options**: Easier to recover access if credentials are lost, as the third party can assist. -- **Security Dependence**: Security depends on the third party's practices and infrastructure. + +- **Managed Private Keys**: The third party has full control over the private keys. You do not possess them. +- **Recovery Options**: It is often easier to recover account access if login credentials are lost, as the custodian can assist. +- **Security Dependence**: The security of your assets is entirely dependent on the custodian's security practices, infrastructure, and operational integrity. +- **Ease of Use**: Provides a simpler user experience, abstracting away the complexities of private key management. ### Use Cases -- **New Users**: Suitable for users who are new to cryptocurrency and prefer a simpler, managed solution. -- **Convenience**: Ideal for users who prioritize convenience and ease of use over full control. + +- **New Users/Beginners**: Suitable for users who are new to cryptocurrency and prefer a simpler, managed solution. +- **Convenience Over Control**: Ideal for users who prioritize convenience and ease of use over full control. ## Non-Custodial Wallets ### What Are They? -Non-custodial wallets are managed by the user, who has full control over their private keys. The user is responsible for the security and management of their keys. + +Non-custodial (or self-custody) wallets are managed directly by the user, who has sole and complete control over their private keys. The user is entirely responsible for the security, backup, and management of these keys. ### Characteristics -- **User-Controlled Private Keys**: The user has full control over their private keys. -- **Higher Security**: Greater security and privacy, as only the user has access to the keys. -- **Responsibility**: The user is solely responsible for backing up and securing their keys. + +- **User-Controlled Private Keys**: The user has exclusive control and possession of their private keys. +- **Eliminates Counterparty Risk**: Assets are not exposed to the risk of a third-party custodian being hacked, becoming insolvent, or freezing funds. Security becomes dependent on the user's own practices. +- **Full Responsibility**: The user is solely responsible for backing up their seed phrase and securing their private keys. Loss of these keys means irreversible loss of funds. +- **Web3 Interaction**: Enable seamless interaction with dApps. ### Use Cases -- **Experienced Users**: Suitable for users who have a good understanding of cryptocurrency and wallet security. -- **Security Prioritization**: Ideal for users who prioritize security and control over convenience. +- **Experienced Users & Developers**: Preferred by users who understand blockchain and wallet security best practices. +- **Security & Control Prioritization**: Ideal for users who prioritize full control over their assets and are willing to undertake the responsibility of self-custody. ## Comparison -| Feature | Custodial Wallets | Non-Custodial Wallets | -|---------------------|--------------------|-----------------------| -| Private Key Control | Third Party | User | -| Security | Dependent on Third Party | High | -| Convenience | High | Moderate to Low | -| Recovery Options | Easy | User Responsibility | -| Use Case | New Users, Convenience | Experienced Users, Security| \ No newline at end of file +| **Feature** | **Custodial Wallets** | **Non-Custodial Wallets** | +| --------------------------- | ------------------------------------------ | ------------------------------------------- | +| **Private Key Control** | Third Party | User | +| **Recovery Options** | Custodian-assisted | User responsibility | +| **Web3 Interaction** | Limited | Direct and Full | +| **Primary Risk** | Counterparty Risk, Centralization | User Error, Loss of Keys | +| **Use Case** | New Users, Trading on CEX, Convenience | Full Control, dApp Use, Long-Term Storage | \ No newline at end of file diff --git a/src/wallet-security/for-beginners-&-small-balances.md b/src/wallet-security/for-beginners-&-small-balances.md new file mode 100644 index 00000000..eb1c21cf --- /dev/null +++ b/src/wallet-security/for-beginners-&-small-balances.md @@ -0,0 +1,43 @@ +--- +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +## For Beginners & Small Balances + +### User Profile + +A user with foundational web3 knowledge who is actively learning and interacting with dApps. The asset value is typically non-critical, where a potential loss would not be financially significant. This profile prioritizes **ease of use** and **learning** over protections against online threats. + +### Primary Goal + +The primary objective is a low-friction setup for **convenience** and **dApp interaction**. This includes frequent transactions, exploring DeFi protocols, and engaging with NFTs. + +### Recommended Setup + +The standard setup for this profile is a **hot wallet**, which provides the necessary internet connectivity for active use. The most common types are: + +* **Browser Extension Wallets:** Integrate directly into a web browser for seamless dApp interaction. +* **Mobile Wallets:** Applications installed on a smartphone, offering convenience and on-the-go access. +* **Desktop Wallets:** Software applications installed on a computer, which can sometimes offer more advanced features than mobile or browser counterparts. + +### Key Considerations & Trade-offs + +While convenient, this setup carries inherent risks that the user must understand and accept. + +* **Online Threat Vector:** As hot wallets are internet-connected, they are inherently vulnerable to malware and exploits targeting the browser or operating system. +* **Supply Chain Risk:** It is critical to download wallet software *only* from official, verified sources. + +### How to Select a Wallet + +When selecting a wallet, prioritize those whose code is **open-source**, as this allows for public scrutiny and independent verification by the security community. For users who are not developers, several platforms provide independent analysis to help evaluate a wallet's security. + +For example, [Wallet Scrutiny](https://walletscrutiny.com/) focuses on verifying if a wallet's code is verifiably open-source. Others, like [Wallet Security Ranking](https://www.coinspect.com/wallets/), provide a security score based on specific criteria such as transaction clarity, protection against known threats, and how it handles dApp permissions. + +Using these tools can provide valuable data points to help you assess a wallet's security posture and make an informed decision. \ No newline at end of file diff --git a/src/wallet-security/hardware-wallets.md b/src/wallet-security/hardware-wallets.md deleted file mode 100644 index f7760fb6..00000000 --- a/src/wallet-security/hardware-wallets.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Finance ---- - -# Hardware Wallets - - -Hardware wallets are physical devices designed to securely store private keys offline. They are one of the most secure options for managing cryptocurrency. It is strongly advised to only purchase hardware wallets directly from the creator or one of their approved vendors, as there has been cases of people falling victim of stolen assets after purchasing hardware wallets on amazon market place, ebay, and other places. - -## Popular Hardware Wallets - -### Ledger Nano X - -- **Description**: A hardware wallet that supports multiple cryptocurrencies and features. -- **Features**: Secure Element chip, mobile compatibility (certain versions), large storage capacity for apps. -- **Incidents**: None reported for the device itself, but Ledger experienced a data breach affecting customer information. -- **Note**: Ledger Nano X has bluetooth, so depending on your security requirements you may want to look at their non-bluetooth wallet options. - -### Trezor Model T - -- **Description**: A touch-screen hardware wallet supporting a wide range of cryptocurrencies. -- **Features**: Open-source firmware, password manager, Shamir backup. -- **Incidents**: Phishing attacks targeting Trezor users through fake websites. - -### KeepKey - -- **Description**: A hardware wallet with a large screen for easy transaction verification. -- **Features**: Aimed to be user-friendly. -- **Incidents**: None reported. - -### BitBox02 - -- **Description**: A compact hardware wallet with a focus on security and privacy. -- **Features**: Dual-chip architecture, native support for Bitcoin and Ethereum, microSD card backup. -- **Incidents**: None reported. - -## Importance of Hardware Wallets - -- **Offline Security**: Private keys are stored offline, significantly reducing the risk of online attacks. -- **Physical Protection**: Hardware wallets are designed to be tamper-resistant and provide a secure environment for key storage. -- **Backup and Recovery**: Most hardware wallets offer robust backup and recovery options to protect against loss or theft. - -## Comparison - -| Wallet | Features | Security Level | Supported Cryptocurrencies | Incident History | -|----------------|---------------------------------|----------------|---------------------------|--------------------| -| Ledger Nano X | Bluetooth, Secure Element | High | 1000+ | Customer data breach (2020) | -| Trezor Model T | Touch screen, Shamir backup | High | 1000+ | Phishing attacks | -| KeepKey | Large screen, ShapeShift integration | High | 40+ | None reported | -| BitBox02 | Dual-chip, microSD backup | High | Bitcoin, Ethereum | None reported | \ No newline at end of file diff --git a/src/wallet-security/intermediates-&-medium-funds.md b/src/wallet-security/intermediates-&-medium-funds.md new file mode 100644 index 00000000..603e0548 --- /dev/null +++ b/src/wallet-security/intermediates-&-medium-funds.md @@ -0,0 +1,39 @@ +--- +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +## For Intermediates & Medium Balances + +### User Profile + +An intermediate user who is comfortable with web3 interactions and is now managing a significant, but not life-altering, amount of assets. This user understands the inherent risks of hot wallets and is actively seeking to upgrade their security posture to protect their capital. + +### Primary Goal + +The main objective is to secure balances against online threats while still retaining the ability to interact with dApps when necessary. This involves **separating the bulk of assets** from daily operational balances. + +### Recommended Setup + +A **hardware wallet** is the core of this setup. This dedicated physical device stores private keys offline in a secure, tamper-resistant environment, acting as a vault for the majority of the user's balances. + +### Key Considerations & Trade-offs + +Adopting a hardware wallet introduces a new set of security considerations focused on physical and supply chain vectors. + +* **Physical Security:** A hardware wallet is a physical asset that must be protected from theft, damage, or coercion. +* **Supply Chain Integrity:** Hardware wallets must *only* be purchased directly from the manufacturer or an authorized reseller to avoid receiving a tampered device. +* **Convenience vs. Security:** Using a hardware wallet introduces friction into the transaction process, as it requires physical access and approval on the device for every signature. + +### How to Select a Hardware Wallet + +* **Open Source:** Evaluate if the wallet's firmware and software are open-source, which allows for public auditing and verification by the security community. +* **Secure Element (SE)** Look for devices with a SE certified, tamper-resistant chip that protects against physical attacks. Check for high assurance ratings like `EAL6+` and features like **attestation**, which verifies the device is genuine. +* **Reputation & Incident:** Investigate the manufacturer's security track record, including their response to past vulnerabilities, data breaches, and overall transparency. +* **Verify Device Integrity**: A legitimate hardware wallet will arrive uninitialized, requiring you to perform the initial setup. Reject any device that comes with a pre-set PIN, a pre-generated recovery phrase, or appears to be already configured, as it is likely compromised. \ No newline at end of file diff --git a/src/wallet-security/private-key-management.md b/src/wallet-security/private-key-management.md new file mode 100644 index 00000000..44da586e --- /dev/null +++ b/src/wallet-security/private-key-management.md @@ -0,0 +1,61 @@ +--- +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +## Private Key & Seed Phrase Management + +The **seed phrase** (or mnemonic phrase) is the master key to a non-custodial wallet, granting complete control over all its derived **private keys** and assets. The management of this phrase is the single most important aspect of self-custody security. + +> ⚠️ If you suspect for even a moment that your private key or seed phrase has been lost, viewed by another person, or exposed digitally (e.g., shown on-screen, copied to a clipboard on a connected device), you must **consider it compromised.** Immediately create a new, secure wallet and transfer all assets to it. + + +### Secure Storage Practices + + +The goal is to protect the seed phrase from both physical threats (theft, fire, water damage) and digital threats (hacking, malware). The foundational principle is to keep your seed phrase offline at all times. + +As soon as a new wallet is created, back it up using one of the following offline methods. Wallet providers do not have access to your seed phrase and cannot help you recover it. + + +- **Physical Written Copies**: Writing the phrase on paper or a notebook is a common starting point. To mitigate risks of loss or damage from fire or water, store multiple copies in secure, geographically separate locations (e.g., a personal safe, a trusted family member's home, a bank deposit box). + +- **Durable Metal Storage**: For superior protection against physical damage, etch or stamp your seed phrase onto a metal plate (e.g., steel, titanium). Commercial products are available for this purpose. These should also be stored in secure, separate locations. + + +### Prohibited Practices + +Under no circumstances should you ever store your seed phrase in any of the following ways: + +- Taking a digital photograph of it. +- Uploading it to cloud storage (iCloud, Google Drive, Dropbox). +- Sending it via text message or any messaging app. +- Sending it in an email, even to yourself. +- Storing it in a plain text file on a computer or phone. +- Sharing it with anyone. Wallet providers will **never** ask for your seed phrase. +- Never use a device obtained from an untrusted source, such as a conference, hackathon, or third-party online marketplace, as it may be tampered with. + +### Ongoing Security Hygiene + +**1. Periodic Security Audits** + +On a recurring basis (e.g., every 6 months), conduct a security review by asking: + +- Do I know the physical location of all my seed phrase backups? +- Are my storage methods still secure and uncompromised? +- If my primary device were destroyed, do I have a clear plan to recover my assets? + +**2. Key Rotation** + +While you can use the same keys for years, it is a best practice to periodically rotate them by moving assets to new wallets. + +**3. Succession Planning** + +Establish a clear, secure protocol for a trusted next-of-kin to access your assets in case of incapacitation or death. This may involve sealed instructions stored with a lawyer or in a safe deposit box. \ No newline at end of file diff --git a/src/wallet-security/secure-multisig-best-practices.md b/src/wallet-security/secure-multisig-best-practices.md index 08b56b09..bd5380d4 100644 --- a/src/wallet-security/secure-multisig-best-practices.md +++ b/src/wallet-security/secure-multisig-best-practices.md @@ -2,39 +2,63 @@ tags: - Security Specialist - Operations & Strategy + - Engineer/Developer +contributors: + - role: wrote + users: [engn33r,pinalikefruit] + - role: reviewed + users: [Coinspect] --- -# Secure Multisig Best Practices +## Multisig Wallets For Advanced Users & High Funds -Multisig setup, management, and administration is a crucial part in maintaining secure access over governance address or protocol funds. Some best practices for how to manage multisigs are explained below. +### User Profile -## Multisig signing addresses +Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for managing protocol treasuries, smart contract ownership, or significant personal/collective assets. -- When a new multisig is created, follow the [Safe documentation for verifying Safe creation took place properly](https://help.safe.global/en/articles/40834-verify-safe-creation). -- A multisig should never be a 1-of-1 multisig, because this setup offers virtually no extra benefit compared to using an EOA address. The exact number of signers and the threshold of signers needed to execute a transaction is for each multisig to determine. -- A unique address should be used for each multisig, and this address should only be used for multisig signing. This helps signers to avoid accidental signing on a different multisig. -- The addresses that are signers of a multisig should all be geographically separated and owned by different individuals. A single person should generally not have control over multiple signing addresses on a single multisig. -- Documentation should be shared between signers indicating which person controls which signing address. Some users may find a benefit from using the Safe address book feature to automatically decode known addresses, but users should be aware that relying on the Safe UI is not a foolproof mechanism. -- Generally, it is recommended that all signers of a multisig be hardware wallets or otherwise highly secured. The more secure each individual signer of the multisig is, the more secure the overall multisig is. -- If some or all multisig signers are in the same physical location, they should not have enough signing keys present to reach quorum. Some projects implement similar rules about signers on multisigs not being on the same plane or vehicle to limit tail risk scenarios. +### Primary Goal -## Multisig secure processes +The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value assets and critical smart contract functions. -- Any time that a new signer is added to the multisig, the address that is to be added should be verified via multiple communication channels (i.e. via Signal message and also by voice call) to protect against the case where a communication channel is compromised. -- A secure process should exist that all multisig signers should follow in order to securely verify and sign any multisig transaction. Without a secure process involving tools such as [safe-tx-hashes-util](https://github.com/pcaversaccio/safe-tx-hashes-util), multisig hacks such as those that impacted Radiant or ByBit are possible. Check out the [secure multisig signing process page](./secure-multisig-signing-process.md) for more details. -- For maximum security, a separate signing device (ideally a laptop running the latest version of a secure OS like Tails or Qubes) should be used that is not used for any other activities. This helps to ensure that there is no malware that may interfere with the signing process. If a multipurpose signing device is used (for example, a developer's primary laptop), there is a much higher risk of malicious interference during the signing process. An alternative approach is booting Tails from an external USB, preferably an encrypted USB such as a Kingston IronKey Keypad 200. -- Signers should consider the scenario where one or more team members loses access to their signing address, especially if the key is stolen or leaked. For this reason, it is not recommended to use a n-on-n multisig where all signers must always sign all transactions. -- If a team has a multichain multisig, the signers for the Safes on different chains should generally be the same, and the threshold should also be the same. -- Multisig teams should add monitoring to their multisig to be alerted of any unexpected changes. One tool that offers this feature is [safe-watcher](https://github.com/Gearbox-protocol/safe-watcher) from the Gearbox team. -- If the multisig controls any time-sensitive actions, such as pausing certain actions in extreme scenarios, the team must plan how to handle such events in a timely manner. +### Core Concept: M-of-N Scheme -## Optional Multisig Feature Configurations +A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals `M` from a total set of authorized signers `N` to execute a transaction. This is known as an `M-of-N` scheme (e.g., 2-of-3, 3-of-5). -- Variety of signing devices (different hardware wallets, etc.) -- RBAC -- Timelock -- A duress code +By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to authorize the movement of funds or execute a privileged action. -## Acknowledgements +### Setup Best Practices -Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and [Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices) +* **Threshold Selection:** The `M-of-N` threshold should be chosen to balance security and operational resilience. Avoid `N-of-N` schemes, as the loss of a single key would result in a permanent loss of access to all funds. + +* **Strategic Signer Distribution:** The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing multiple signer keys on the same device or in the same physical location negates the security benefits. Effective distribution strategies include: + * Using different hardware wallet models and manufacturers. + * Maintaining geographical separation for devices holding signer keys. + * Assigning signer keys to different trusted individuals within an organization. + * Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software vulnerability. + +* **Practice on Testnet:** Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network. + +* **Timelocks:** Enforce a mandatory delay between the approval of a transaction and its execution. This provides a critical window for the community or team to detect and react to malicious proposals. + +* **Role-Based Access Control (RBAC):** Implement modules that grant specific, limited permissions to certain addresses (e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege. + +### Operational Best Practices + + +* **Signer Key Revocation and Replacement:** A feature of multisigs is the ability to add, remove, or replace signer keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate funds. + +* **Secure Signing Environment:** For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference. + +* **Independent Transaction Verification:** Before signing, always verify the raw transaction data (target address, function call, parameters) to ensure it matches the intended operation. + +* **Out-of-Band Verification for Admin Changes:** Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks. + +* **Active Monitoring:** Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like [Safe Watcher](https://github.com/Gearbox-protocol/safe-watcher) ). + +* **Documented Procedures:** Maintain clear, secure, and accessible documentation for all multisig procedures, including transaction creation, signing, and emergency recovery plans. + + + +### Acknowledgements + +Some ideas were borrowed from the [EF's multisig SOP notes](https://notes.ethereum.org/@fredrik/multisig-sop) and [Manifold Finance multisig best practices](https://hackmd.io/@manifoldx/multisig-best-practices). \ No newline at end of file diff --git a/src/wallet-security/secure-multisig-signing-process.md b/src/wallet-security/secure-multisig-signing-process.md index 1209c21d..c39b9968 100644 --- a/src/wallet-security/secure-multisig-signing-process.md +++ b/src/wallet-security/secure-multisig-signing-process.md @@ -2,60 +2,53 @@ tags: - Security Specialist - Operations & Strategy + - Engineer/Developer +contributors: + - role: wrote + users: [engn33r,pinalikefruit] + - role: reviewed + users: [Coinspect] --- -# Secure Multisig Signing Process +# Verifying Multisig Transactions -Multisig security has always been important, but it has received extra scrutiny since the ByBit hack in late February 2025 that involve a compromise of the commonly-used Safe UI. Every multisig signer should have a secure and thorough process to make sure that the transaction they are signing is, in fact, the action that they expect. The following steps reduce dependencies on the Safe UI and provide greater assurance that the multisig signer is signing a valid transaction and not a malicious one. +The security of a multisig wallet relies on each signer independently verifying what they are signing. A compromised web interface could present a legitimate-looking transaction while tricking a hardware wallet into signing a malicious one. -## Step 1: Connecting a hardware wallet +The verification process is divided into two distinct phases: signing the off-chain message and executing the on-chain transaction. -Hardware wallets offer better security than most software wallets, so it's recommended that all multisig signer addresses are from hardware wallets. If you are using a browser extension like Metamask, Rabby, or Frame as an intermediary, you should consider the data shown in the browser extension as similar to the data shown in the Safe UI: not 100% trustworthy if your device has been hacked, but another data point that can be worth examining to make sure all the data matches your expectations to confirm there are no anomalies. +## Phase 1: Signing the Off-Chain Message -## (Optional) Step 2: Preparing the ABI +When you are the first signer or are adding your signature to a transaction that has not yet met its threshold, you are not sending an on-chain transaction. Instead, you are signing a structured, off-chain message that conforms to the **EIP-712** standard. -The transaction proposer should create the transaction using the Safe frontend. -If the transaction is sent to a non-verified contract, the Safe UI requires the contract ABI. -If you have the correct code repository stored locally, one way to generate the contract ABI is using the command: +**Goal**: To confirm that the cryptographic hash displayed on your hardware wallet exactly matches the hash of the transaction you intend to approve. -```bash -forge inspect src/Factory/VaultFactory.sol:VaultFactory abi > ABI.txt -``` +### Process -## Step 3: Transaction proposer prepares the first signature +1. **Initiate Signing**: Start the signing process in the multisig wallet's web interface. +2. **Verify on Hardware Wallet**: Your hardware wallet will display an EIP-712 hash for you to sign. +3. **Independently Compute Hash**: Use an independent, local tool like **[safe-hash](https://github.com/Cyfrin/safe-hash-rs)** to re-calculate the expected hash. The tool will ask for the transaction's parameters (nonce, `to`, `value`, `data`, etc.) to generate the hash locally on your machine. + > For less technical users, a web-based tool like **[Safe Utils](https://safeutils.openzeppelin.com/)** can perform this calculation, but a local command-line tool offers superior security against browser-based attacks. +4. **Compare Hashes**: Compare the `SafeTxHash` generated by the local tool with the hash displayed on your hardware wallet's screen. **They must match perfectly.** +5. **Sign**: If the hashes match, you can confidently sign the message on your hardware wallet. This confirms you are approving the correct transaction, even if the web UI has been compromised. -Before the transaction proposer gives the first signature for the transaction, they should verify the signature using [pcaversaccio's safe-tx-hashes-util tool](https://github.com/pcaversaccio/safe-tx-hashes-util). There are two ways to do this: +## Phase 2: Executing the On-Chain Transaction -- Option 1: Use the [interactive mode](https://github.com/pcaversaccio/safe-tx-hashes-util?tab=readme-ov-file#interactive-mode) feature to generates a signature for transactions that have not been initialized. This mode prompts the user for each input as needed. An example command for using the tool to verify the first signature is with a command like: +Once a transaction has the required M-of-N signatures, it can be executed. This involves submitting a final on-chain transaction that calls the `execTransaction` function on the multisig contract, passing in all the previously signed data. -```bash -./safe_hashes.sh --network base --address 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F --nonce 7 --interactive -``` +**Goal**: To confirm that the on-chain transaction being sent correctly encapsulates the multisig transaction you and other signers approved. -- Option 2: Modify the script by editing the endpoint variable (which builds the URL that calls the Safe API) to include the "trusted=false" as suggested by [this footnote](https://github.com/pcaversaccio/safe-tx-hashes-util?tab=readme-ov-file#user-content-fn-1-091bb929bedb25d28c91e9a9c9456df5). If there are multiple transactions with the same nonce, the tool will provide a warning and ask you to choose a specific transaction. An example command for using the tool to verify the first signature (after custom modifying the bash script) is with a command like: +### Process -```bash -./safe_hashes.sh --network base --address 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F --nonce 7 -``` +1. **Initiate Execution**: In the multisig interface, start the execution of the fully signed transaction. +2. **Verify Calldata**: Your hardware wallet will prompt you to sign a new on-chain transaction. It will display the raw transaction data (calldata), which should show a call to the `execTransaction` function. +3. **Decode and Compare**: Use a calldata decoder (e.g.,[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)) to parse the data shown on your hardware wallet. +4. **Confirm Parameters**: Carefully check the decoded parameters within the `execTransaction` call, especially the internal destination address (`to`), `value`, and `data` payload. Ensure they match the original, intended transaction. +5. **Sign and Broadcast**: If the calldata is correct, sign the transaction on your hardware wallet to broadcast it to the network. -## Step 4: Simulate the transaction +## Operational Best Practices -After the transaction is proposed and signed by the proposer, it is possible for the proposer to simulate the transaction on Tenderly (although this feature also may have been temporarily removed after the ByBit hack?). The simulation results are less useful if the contracts are not verified, but the simulation will at least show whether the transaction reverts or not. +> ⚠️ **Beware of `DELEGATECALL`**: In a smart contract multisig transaction, an `operation: 1 (DELEGATECALL)` is dangerous if the target contract is not explicitly known and trusted. This opcode gives another contract full control over your wallet's context and storage. -## Step 5: Multisig signers signing an existing queued transaction - -Before any other multisig transaction signers (after the tx proposer) sign the transaction, they should: - -- Use [pcaversaccio's safe-tx-hashes-util tool](https://github.com/pcaversaccio/safe-tx-hashes-util) to validate the signature on their hardware wallet instead of signing blindly. -The command looks like `./safe_hashes.sh --network base --address 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F --nonce 234`. -- Signers should also use the Tenderly simulation built-in to the Safe UI to verify that the transaction does not revert and returns the expected end state. -- Signers should also double check that the "To" address in the transaction is a valid Safe address listed in the [Safe docs](https://docs.safe.global/advanced/smart-account-supported-networks?version=v1.4.1) or in the [Safe deployments repo](https://github.com/safe-global/safe-deployments) and additionally confirm that the contract was not very recently deployed. The safe-tx-hashes-util tool does a basic check for this, but a more careful manual check is recommended. -- If ANY transaction error is identified in the multisig transaction, the transaction batch should NOT be signed, and instead new multisig transactions should be created individually (without batching). - -Note: although it is not as secure as using the CLI tool, less technical users can use the OpenZeppelin [Safe Utils website](https://safeutils.openzeppelin.com/) to receive similar results (although less trustworthy if the browser or UI is hacked) -Note: These steps are similar to what is found in [this hackernoon article by Alberto Cuesta Cañada](https://hackernoon.com/how-to-review-a-governance-action) about secure governance action processes. -Optional: It's recommended to implement a manual review of raw transaction payloads using tools like Etherscan’s input data decoder or [this calldata decoder](https://calldata.swiss-knife.xyz/decoder). You will need to use this tool recursively for batched transactions. Simulating with an alternative to Tenderly such as [temper](https://github.com/EnsoBuild/temper) is another option. - -## (Optional) Step 6: Using an alternative Safe UI - -Consider using a self-hosted Gnosis Safe frontend for this entire process to completely avoid the public Gnosis Safe UI. Examples include [safe-infrastructure](https://github.com/safe-global/safe-infrastructure), [eternalsafe](https://github.com/eternalsafe/wallet/tree/v1), [safer](https://github.com/morpho-labs/safer), [safe-reserve](https://github.com/Gearbox-protocol/safe-reserve), and [gnosis-hosted](https://github.com/hoprnet/gnosis-hosted). +- **Transaction Simulation**: Before signing, use a simulator like **[Tenderly](https://tenderly.co/)** or **[Alchemy](https://www.alchemy.com/docs/reference/simulation)** to preview the transaction's outcome. This helps confirm that it will not revert and will result in the expected state changes. +- **Hardware Wallet Standard**: All multisig signers should use hardware wallets to protect their keys from online threats. Data shown in a browser extension wallet should be treated with the same skepticism as data in the web UI. +- **Alternative Frontends**: To further reduce reliance on a single public UI, consider using an alternative or self-hosted multisig interface. diff --git a/src/wallet-security/signing-schemes.md b/src/wallet-security/signing-schemes.md deleted file mode 100644 index 9ebe220a..00000000 --- a/src/wallet-security/signing-schemes.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -tags: - - Engineer/Developer - - Security Specialist ---- - -# Signing schemes - - -Different signing schemes provide varying levels of security, control, and use cases for managing cryptocurrency assets. Here’s an overview of common signing schemes, their analogies, use cases, and security implications. - -## Externally Owned Accounts (EOA) -- **Analogy:** Traditional bank account with a single owner. -- **Control:** Single private key controls the account. -- **Use:** Basic transactions and smart contract interactions. -- **Security:** Single point of failure if the single key is compromised. - -## Multisignature (Multisig) -- **Analogy:** Joint bank account requiring multiple signatures. -- **Control:** Multiple private keys are needed to authorize transactions. -- **Use:** Common in organizational settings for shared control. -- **Security:** High security, reduces risk of single point of failure. - -## Smart Contract Wallets (Safes) -- **Analogy:** Digital safe with programmable access controls. -- **Control:** Controlled by smart contracts with defined rules. -- **Use:** Advanced use cases, including DeFi and automated transactions. -- **Security:** Generally seen as High, but depends on the smart contract’s security and configuration. - -## Threshold Signatures -- **Analogy:** Similar to a multi-lock safe that requires a subset of keys from authorized staff. -- **Control:** Requires a minimum number of signatures out of a predefined set. -- **Use:** Efficient and private alternative to multisig. -- **Security:** Reduces risk while maintaining group control. - -## Social Recovery Wallets -- **Analogy:** Trusted friends helping to recover a lost key. -- **Control:** Designated trusted contacts can help recover the account. -- **Use:** Individual use with recovery options. -- **Security:** High, balances security with ease of recovery from its community-based security model. - -## Delegated Signing/Proxy Contracts -- **Analogy:** Authorized bank agent signing on behalf of the account owner. -- **Control:** Transactions are signed by a proxy on behalf of the user. -- **Use:** Delegating transaction signing to trusted services. -- **Security:** Moderate, relies on the security of the proxy. - -## Account Abstraction (AA) -- **Analogy:** Like a shape-shifting lock, where the way it opens can change over time. -- **Control:** User accounts as smart contracts. -- **Use:** User-friendly wallets, customizable security policies, complex rules and operations for transactions. -- **Security:** High, but depends on implementation. - - -## Comparison - -| Scheme | Analogy | Control | Use Case | Security | -|--------------------------|-------------------------------------|-----------------------------|-------------------------------------|---------------------------| -| Externally Owned Accounts| Traditional bank account | Single private key | Individual use | High risk if compromised | -| Multisignature | Joint bank account | Multiple private keys | Team/organization funds management | High security | -| Smart Contract Wallets | Digital safe | Smart contracts | DeFi, automated transactions | High, depends on contract | -| Threshold Signatures | Multi-lock safe | Subset of keys | Decentralized organizations | High security | -| Social Recovery Wallets | Trusted friends for recovery | Guardians | Individual use with recovery options| High security | -| Delegated Signing | Authorized agent | Proxy | Delegated transaction signing | Moderate security | -| Account Abstraction | Abstracting account management | Smart contracts | User-friendly wallets | High, depends on implementation | \ No newline at end of file diff --git a/src/wallet-security/signing-verification.md b/src/wallet-security/signing-verification.md new file mode 100644 index 00000000..a76e238e --- /dev/null +++ b/src/wallet-security/signing-verification.md @@ -0,0 +1,36 @@ +--- +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +# Signing & Verification + +This section provides a guide to transaction verification, from basic EOA interactions to advanced multisig operations. + +The rule is to **never sign blindly**. Always take the time to verify what your wallet is asking you to approve. A compromised dApp front-end or a misunderstanding of a transaction's parameters can lead to a complete loss of funds, even with a wallet that is not compromised. + +### Core Principles of Secure Signing + +Before diving into specific use cases, it's critical to adopt a security-first mindset built on these foundational principles: + +- **Verify, Don't Trust**: Never trust a user interface blindly. The raw transaction data is the ground truth of what you are authorizing. Always use independent tools to confirm that what you see is what you sign. +- **Simulate Before Signing**: Before approving any non-trivial transaction, use a simulation tool. These tools act as a "sandbox," showing you the human-readable outcome before you commit, protecting you from unexpected results and malicious contracts. +- **The Hardware Wallet is the Source of Truth**: Your hardware wallet's trusted display is your last line of defense against UI spoofing. If the information on your computer screen does not perfectly match what is on your hardware device, reject the transaction immediately. +- **Demand Clear Signing**: Prioritize hardware and software that can decode and display a transaction's intent in a human-readable format. If a wallet requires "blind signing" (approving a raw, unreadable hash), you are accepting a significant level of risk. + +### In This Section + +This chapter breaks down transaction verification into key areas: + +- **[Standard Transaction Verification](./verifying-standard-transactions.md)**: An overview of the foundational security principles that apply to all types of transactions. +- **[Verifying Multisig Transactions](./secure-multisig-signing-process.md)**: A detailed guide to the two-phase process of securely signing and executing multisig transactions, including how to verify EIP-712 hashes and `execTransaction` calldata. +- **[Verifying EIP-7702 Transactions](./verifying-7702.md)**: An analysis of the new security considerations introduced by EIP-7702, which allows EOAs to temporarily act as smart contracts, with specific guidance for both users and developers. + +To apply these principles, this framework provides a curated list of verification and simulation tools in the **[ Tools & Resources](./tools-&-resources.md)**. \ No newline at end of file diff --git a/src/wallet-security/software-wallets.md b/src/wallet-security/software-wallets.md deleted file mode 100644 index 9b7fb74b..00000000 --- a/src/wallet-security/software-wallets.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -tags: - - Engineer/Developer - - Security Specialist ---- - -# Software Wallets - - -Software wallets are applications designed to manage cryptocurrency assets. -They are often convenient and offer a range of features for different use cases, often provide easy access to DeFi applications, supports hardware wallets and has built in features such as token swapping, staking and more. - -A list of wallets can be found on the [ethereum.org](https://ethereum.org/en/wallets/) website. - -For a comprehensive comparison of different software wallets, you can visit [walletcompare.xyz](https://walletcompare.xyz). This website provides detailed comparisons of various wallets based on features, security, user experience, and more. - -Additionally, for in-depth scrutiny and reviews of software wallets, you can refer to [Wallet Scrutiny](https://walletscrutiny.com). This platform evaluates wallets for transparency, security, and overall reliability, helping users make informed decisions about which wallet to use. \ No newline at end of file diff --git a/src/wallet-security/tools-&-resources.md b/src/wallet-security/tools-&-resources.md new file mode 100644 index 00000000..06e0baf2 --- /dev/null +++ b/src/wallet-security/tools-&-resources.md @@ -0,0 +1,47 @@ +--- +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +# Tools & Resources + +This section provides a curated list of tools and resources to help users select wallets, practice safe signing habits, and verify transactions. Using these tools is a critical part of a robust security strategy. + +## Wallet Selection + +Before choosing a wallet, it is essential to consult independent, community-trusted resources. + +- **[ethereum.org/wallets](https://ethereum.org/en/wallets/find-wallet/)**: The official, community-maintained list of wallets, filterable by features. A reliable starting point for discovering wallets. +- **[Wallet Scrutiny](https://walletscrutiny.com/)**: An in-depth review site that focuses on transparency, verifiability, and reproducibility. It flags wallets that are closed-source or have other potential security concerns. +- **[Wallet Security Ranking](https://www.coinspect.com/wallets/)**: Evaluates wallets by permissions, intent clarity, device security, and threat prevention to help users choose safer, more trustworthy options. +- **[Wallet Beat](https://beta.walletbeat.eth.limo/wallet/summary/)**: Aims to provide a comprehensive list of wallets, their functionality, practices, and support for certain standards. + +## Transaction Simulation + +Transaction simulators allow you to preview the exact outcome of a transaction before signing it, preventing errors and security risks. + +- **[Tenderly](https://tenderly.co/)**: A platform that allows you to simulate transactions and preview, helping to prevent transaction failures, security risks, and unnecessary gas costs. +- **[Alchemy Simulation APIs](https://www.alchemy.com/docs/reference/simulation)**: An API suite that predicts the precise impact of a transaction before it reaches the blockchain. + +## Transaction Verification + +These tools are designed to help you independently verify the integrity of transaction data, especially for multisig operations. + +- **[safe-hash](https://github.com/Cyfrin/safe-hash-rs)**: A command-line tool for locally verifying Safe transaction data and EIP-712 messages before signing. It is designed to protect against phishing by allowing you to independently generate the hash your wallet will ask you to sign. +- **[Safe Utils](https://safeutils.openzeppelin.com/)**: A user-friendly web interface for calculating and verifying Safe transaction hashes. While convenient, remember the security advantages of using a local, offline tool like `safe-hash` for high-value transactions. +- **[calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder)**: Web-based tool for quick decoding of transaction data. +- **[Foundry cast](https://book.getfoundry.sh/reference/cast/cast-decode-calldata)**: A powerful command-line tool for local, offline decoding. + +## Security Training + +These tools allow you to practice identifying threats in a safe, simulated environment. + +- **[Wise Signer](https://wise-signer.cyfrin.io/)**: An interactive platform that challenges users to identify safe and dangerous transactions before signing them. It is an excellent tool for learning to recognize common phishing attacks and deceptive transaction patterns without risking real assets. +- **[Web3 Wallet Security Courses](https://updraft.cyfrin.io/career-tracks/web3-wallet-security/)**: Offers a structured curriculum for hands-on security training, guiding users from foundational concepts in "Web3 Wallet Security Basics" to advanced techniques. The advanced course covers critical topics like Safe multisig configuration, EIP-712 signature verification, and real-world hack analysis. +- **[How to Multisig](https://howtomultisig.com/)**: A dedicated resource with best practices on how to implement secure standard operating procedures for multisig wallets. \ No newline at end of file diff --git a/src/wallet-security/verifying-7702.md b/src/wallet-security/verifying-7702.md new file mode 100644 index 00000000..882bf47f --- /dev/null +++ b/src/wallet-security/verifying-7702.md @@ -0,0 +1,39 @@ +--- +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +# Using EIP-7702 + +The Pectra network upgrade introduces **EIP-7702**, which allows a standard Externally Owned Account (EOA) to temporarily function like a smart contract wallet. This is achieved via a new transaction type (`0x04`) that lets an EOA delegate its authority to a smart contract's code for the duration of a transaction or until it's changed. + +## Benefits of EIP-7702 + +This EIP unlocks several key user experience improvements: + +- **Transaction Batching**: Users can combine multiple operations (e.g., an ERC-20 `approve` and a `swap`) into a single, atomic transaction, saving on gas fees and reducing confirmation fatigue. +- **Gas Sponsorship**: It enables third parties to pay for a user's transaction fees, which can simplify onboarding and abstract away gas management for the user. +- **Privilege De-escalation**: Users can delegate to contracts that enforce specific permissions, such as daily spending limits or interactions with only certain dApps. + +## Risks of EIP-7702 + +While powerful, this feature introduces a new attack vector. If an attacker tricks a user into signing a message that sets the wallet's code to a malicious contract, the attacker can gain full control and drain all assets. + +- **Phishing Attacks**: The primary threat is phishing sites or scams that trick users into signing a `SetCode` delegation to a malicious contract under the guise of a wallet "upgrade." +- **Multi-Chain Replay Attacks**: A signature authorizing a delegation with `chain ID 0` can be replayed on other EVM chains. An attacker could deploy a malicious contract at the same address on a different chain and use the replayed signature to take control there. + +## Guidance for Users + +- **Trust Your Wallet's Implementation**: Major wallets mitigate phishing risks by **hardcoding** the *only* valid delegation contract. This prevents malicious websites from tricking you into delegating to an unsafe contract. Only approve delegations to contracts vetted and integrated by your wallet provider. +- **Verify Delegation Targets**: Only delegate your account to contracts that are well-known and audited. +- **Understand Revocation**: You can revoke a delegation and return your account to a standard EOA by authorizing a new transaction that sets the delegation address to the zero address (`0x0000000000000000000000000000000000000000`). +- **Protect Your Private Key**: Delegation does not eliminate the fundamental risk of a private key compromise. If your key is stolen, an attacker can still authorize delegations. +- **Beware of Phishing**: Be skeptical of any request to "upgrade" or "enable" smart account features, especially if it comes from an external link or pop-up. + +> ⚠️ Wallets will only prompt you to switch to a smart account within the wallet's native. Any request to do so via email, a website, or a direct message is a phishing scam. diff --git a/src/wallet-security/verifying-standard-transactions.md b/src/wallet-security/verifying-standard-transactions.md new file mode 100644 index 00000000..ec3204ef --- /dev/null +++ b/src/wallet-security/verifying-standard-transactions.md @@ -0,0 +1,42 @@ +--- +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [pinalikefruit] + - role: reviewed + users: [Coinspect] +--- + +# Verifying Standard Transactions (EOA) + +When interacting with a dApp using a standard Externally Owned Account (EOA) via a wallet, you must verify several key components of the transaction request before signing. + +### 1. Verify the Origin + +- **What to check**: The URL of the website initiating the transaction request. +- **Why it's critical**: A malicious site can perfectly clone a legitimate dApp's interface to trick you into signing a malicious transaction. Always ensure you are on the correct, official domain. + +### 2. Verify the Smart Contract Address + +- **What to check**: The contract address listed under a field like "Interacting With" in your wallet's transaction prompt. +- **Why it's critical**: This is the actual on-chain address your transaction is being sent to. A malicious dApp will substitute a fraudulent contract address here. +- **Verification Methods**: + - **Official Documentation**: The most reliable source. Find the "Contract Addresses" or "Deployments" section in the protocol's official documentation and confirm the address matches. + - **Block Explorer (Etherscan, Blockscout, etc.)**: Paste the address into a block explorer. Look for verification checkmarks, official labels, and a healthy transaction history. + +### 3. Verify the Function and Parameters + +- **What to check**: The function name (e.g., `depositETH`) and the parameters in the "Data" tab of your wallet. +- **Why it's critical**: This is the exact *action* you are authorizing the smart contract to perform. A malicious transaction might look legitimate on the surface but contain a harmful function call. +- **Verification Methods**: + - **Cross-reference with Documentation**: The protocol's developer documentation will define the function and what each parameter represents. + - **Scrutinize Recipient Addresses**: For any function that directs assets (e.g., `onBehalfOf`, `recipient`, `to`), ensure the address is your own or the intended recipient. + - **Understand Amounts**: Verify token amounts, paying attention to the number of decimals. + +### 4. Sanity-Check the Network Fee (Gas) + +- **What to check**: The estimated gas fee for the transaction. +- **Why it's critical**: An unusually high gas fee for a simple operation can be a red flag, potentially indicating an inefficient or malicious contract designed to waste user funds. +