March 2, 2022
Portfolio
Unusual

Securing Web3

No items found.
Securing Web3Securing Web3
All posts
Editor's note: 

Editor's note: This is a deep dive on the state of cybersecurity in Web3. A shorter version was originally posted on TechCrunch, and Wei explained more of his thinking in this thread.

Web3 is completely different … and exactly the same when it comes to security


In both Web1 and Web2, security models changed in tandem with application architectures to help unlock entirely new economies. In Web1, Secure Sockets Layer (SSL) was pioneered by Netscape to provide secure communication between user browsers and those servers. Trusted Web2 intermediaries such as Google, Microsoft, Amazon, and certificate authorities played a central role in driving implementation of Transport Layer Security (TLS), the successor to SSL. 


The same will happen for Web3. This is the key reason why investment in new Web3 security companies increased last year more than 10x to over $1 billion


The success of Web3 hinges on innovation to solve new security challenges created by different application architectures. In Web3, decentralized applications or “dApps” are built without relying on the traditional application logic and database layers that exist in Web2; instead, a blockchain, network nodes, and smart contracts are used to manage logic and state. Users still access a front-end, which connects to those nodes, to update data such as publishing new content or making a purchase. These activities require users to sign transactions using their private keys, typically managed with a wallet, a model which is intended to preserve user control and privacy. Transactions on the blockchain are fully transparent, publicly accessible, and immutable (meaning they cannot be changed). 


Like any system, this design has security tradeoffs. The blockchain does not require actors to be trusted as in Web2, but making updates to address security problems is harder. Users get to maintain control over their identities, but no intermediaries exist to provide recourse in the event of attacks or key compromises (e.g., how Web2 providers can revert stolen funds or reset passwords). Wallets can still leak sensitive information like an Ethereum address – it’s still software, which is never perfect.


These tradeoffs rightfully prompt significant security concerns, but they should not stymie Web3 momentum and, practically speaking, they are unlikely to. Consider the parallels to Web1 and Web2 again. The initial versions of SSL/TLS had critical vulnerabilities. Early security tooling was rudimentary at best and became more robust over time. Web3 security companies and projects like Certik, Forta, Slither, and Securify are the equivalent of the code scanning and application security testing tools that were originally developed for Web1 and Web2 applications. However, in Web2, a substantial part of the security model is about response. In Web3, where transactions cannot be changed once executed, mechanisms must be built in to verify transactions should happen in the first place. In other words, security has to be exceptionally good at prevention. 


This means the Web3 community-at-large has to figure out how best to technically address systemic weaknesses to head off new attack vectors that target everything from cryptographic primitives to smart contract vulnerabilities. In parallel, there are at least four initiatives that would advance a preventative Web3 security model:


Source-of-truth data for vulnerabilities

There needs to be a source of truth for known Web3 vulnerabilities and weaknesses. Today, the National Vulnerability Database provides the core data for vulnerability management programs. Web3 needs a decentralized equivalent. For now, incomplete information lives scattered across places such as SWC Registry, Rekt, Smart Contract Attack Vectors, and DeFi Threat Matrix. Bug bounty programs such as those run by Immunefi are meant to surface new weaknesses.


Security decision-making norms
The decision-making model for critical security design choices and individual incidents in Web3 is currently unknown. Decentralization means that no one owns the problems, and the ramifications for users can be significant. Examples such as the recent Log4j vulnerability are cautionary tales for leaving security up to a decentralized community. 


There needs to be greater clarity regarding how Decentralized Autonomous Organizations (DAOs), security experts, providers such as Alchemy and Infura, and others collaborate to manage emergent security issues. There are applicable lessons from how large open source communities have formed the OpenSSF and CNCF advisory groups and established processes to tackle security issues. 


Authentication and signing

Most dApps, including the most prominent ones, today do not authenticate nor sign their API responses. This means that when a user’s wallet retrieves data from these apps, there is a gap in verifying that the response is coming from the intended app and that the data has not been tampered with in some way. In a world where apps do not employ basic security best practices, it is left to users to determine their security posture and trustworthiness, a task that is practically impossible. At a minimum, there need to be better methods to surface risks to users.


Easier, user-controlled key management

Cryptographic keys underpin users’ ability to transact in the Web3 paradigm. Cryptographic keys are also notoriously hard to manage properly; entire businesses have been and continue to be built around managing keys. 


The complexity and risk involved with managing private keys is the primary consideration that drives users to choose hosted wallets rather than non-custodial ones, however, the use of hosted wallets leads to two tradeoffs: (1) it results in new “intermediaries” like Coinbase, which detract from the fully decentralized direction of Web3, and (2) it restricts users’ ability to take advantage of all that Web3 has to offer. Ideally, further security innovation will provide users with both better usability and protections for non-custodial scenarios.


It is worth noting that the first two initiatives center more around people and processes while the third and fourth initiatives will require technological changes. Getting new technology, nascent processes, and a large number of users aligned is what makes figuring out Web3 security hard. At the same time, one of the most encouraging changes is that Web3 security innovation is happening in the open, and we should never underestimate how that can lead to creative solutions.


All posts

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

All posts
March 2, 2022
Portfolio
Unusual

Securing Web3

No items found.
Securing Web3Securing Web3
Editor's note: 

Editor's note: This is a deep dive on the state of cybersecurity in Web3. A shorter version was originally posted on TechCrunch, and Wei explained more of his thinking in this thread.

Web3 is completely different … and exactly the same when it comes to security


In both Web1 and Web2, security models changed in tandem with application architectures to help unlock entirely new economies. In Web1, Secure Sockets Layer (SSL) was pioneered by Netscape to provide secure communication between user browsers and those servers. Trusted Web2 intermediaries such as Google, Microsoft, Amazon, and certificate authorities played a central role in driving implementation of Transport Layer Security (TLS), the successor to SSL. 


The same will happen for Web3. This is the key reason why investment in new Web3 security companies increased last year more than 10x to over $1 billion


The success of Web3 hinges on innovation to solve new security challenges created by different application architectures. In Web3, decentralized applications or “dApps” are built without relying on the traditional application logic and database layers that exist in Web2; instead, a blockchain, network nodes, and smart contracts are used to manage logic and state. Users still access a front-end, which connects to those nodes, to update data such as publishing new content or making a purchase. These activities require users to sign transactions using their private keys, typically managed with a wallet, a model which is intended to preserve user control and privacy. Transactions on the blockchain are fully transparent, publicly accessible, and immutable (meaning they cannot be changed). 


Like any system, this design has security tradeoffs. The blockchain does not require actors to be trusted as in Web2, but making updates to address security problems is harder. Users get to maintain control over their identities, but no intermediaries exist to provide recourse in the event of attacks or key compromises (e.g., how Web2 providers can revert stolen funds or reset passwords). Wallets can still leak sensitive information like an Ethereum address – it’s still software, which is never perfect.


These tradeoffs rightfully prompt significant security concerns, but they should not stymie Web3 momentum and, practically speaking, they are unlikely to. Consider the parallels to Web1 and Web2 again. The initial versions of SSL/TLS had critical vulnerabilities. Early security tooling was rudimentary at best and became more robust over time. Web3 security companies and projects like Certik, Forta, Slither, and Securify are the equivalent of the code scanning and application security testing tools that were originally developed for Web1 and Web2 applications. However, in Web2, a substantial part of the security model is about response. In Web3, where transactions cannot be changed once executed, mechanisms must be built in to verify transactions should happen in the first place. In other words, security has to be exceptionally good at prevention. 


This means the Web3 community-at-large has to figure out how best to technically address systemic weaknesses to head off new attack vectors that target everything from cryptographic primitives to smart contract vulnerabilities. In parallel, there are at least four initiatives that would advance a preventative Web3 security model:


Source-of-truth data for vulnerabilities

There needs to be a source of truth for known Web3 vulnerabilities and weaknesses. Today, the National Vulnerability Database provides the core data for vulnerability management programs. Web3 needs a decentralized equivalent. For now, incomplete information lives scattered across places such as SWC Registry, Rekt, Smart Contract Attack Vectors, and DeFi Threat Matrix. Bug bounty programs such as those run by Immunefi are meant to surface new weaknesses.


Security decision-making norms
The decision-making model for critical security design choices and individual incidents in Web3 is currently unknown. Decentralization means that no one owns the problems, and the ramifications for users can be significant. Examples such as the recent Log4j vulnerability are cautionary tales for leaving security up to a decentralized community. 


There needs to be greater clarity regarding how Decentralized Autonomous Organizations (DAOs), security experts, providers such as Alchemy and Infura, and others collaborate to manage emergent security issues. There are applicable lessons from how large open source communities have formed the OpenSSF and CNCF advisory groups and established processes to tackle security issues. 


Authentication and signing

Most dApps, including the most prominent ones, today do not authenticate nor sign their API responses. This means that when a user’s wallet retrieves data from these apps, there is a gap in verifying that the response is coming from the intended app and that the data has not been tampered with in some way. In a world where apps do not employ basic security best practices, it is left to users to determine their security posture and trustworthiness, a task that is practically impossible. At a minimum, there need to be better methods to surface risks to users.


Easier, user-controlled key management

Cryptographic keys underpin users’ ability to transact in the Web3 paradigm. Cryptographic keys are also notoriously hard to manage properly; entire businesses have been and continue to be built around managing keys. 


The complexity and risk involved with managing private keys is the primary consideration that drives users to choose hosted wallets rather than non-custodial ones, however, the use of hosted wallets leads to two tradeoffs: (1) it results in new “intermediaries” like Coinbase, which detract from the fully decentralized direction of Web3, and (2) it restricts users’ ability to take advantage of all that Web3 has to offer. Ideally, further security innovation will provide users with both better usability and protections for non-custodial scenarios.


It is worth noting that the first two initiatives center more around people and processes while the third and fourth initiatives will require technological changes. Getting new technology, nascent processes, and a large number of users aligned is what makes figuring out Web3 security hard. At the same time, one of the most encouraging changes is that Web3 security innovation is happening in the open, and we should never underestimate how that can lead to creative solutions.


All posts

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.