Temple Wallet web extension security audit report summary
For: Tezos Foundation
Confidential. 09.10.2021, updated 22.02.2022
Overview and Executive summary
In August-October 2021, Tezos Foundation and Madfish requested Cossack Labs to offer an opinion on improving security and cryptography aspects of Temple Wallet’s source code and cryptographic design.
Temple Wallet, a browser extension cryptocurrency wallet for the Tezos ecosystem, provides users with the ability to manage XTZ tokens (any FA 1.2 and FA 2 tokens) and interact with decentralized applications.
As Temple Wallet doesn’t have a public set of security claims and risk statement, we assume that wallet’s users expect the same level of security as any “hot” non-custodial crypto-wallet (based on other wallets and their explicit guarantees):
Temple Wallet stores users’ accounts securely, does not leak keys, passwords, sensitive data, prevents unauthorized access to the wallet and prevents unauthorized transaction sending and signing.
We have found out that if Temple Wallet users understand:
- their responsibilities of protecting their account credentials,
- limitations of web extensions and hot non-custodial wallets,
- their responsibility of ensuring host OS and browser security prior to unsealing the wallet,
… then users' data, keys and transactions are acceptably protected with Temple Wallet’s security measures.
However, we found a number of broken security controls, missing security controls, risky design decisions and application security bugs in these areas:
- cryptographic design and implementations,
- application security,
- platform trust,
- code quality,
- supply chain risks,
- educating users about limitations of web extensions and non-custodial wallets,
- user’s susceptibility to deanonymization.
Under unfavorable circumstances, these issues could lead to sensitive data leakage, triggering unauthorized transactions, losing wallet’s data, deanonymizing users, or potentially DoS-ing the network with malformed transactions.
As the main goals of this engagement were to improve the security of Temple Wallet, we’ve also separately provided numerous suggestions on application security, cryptographic flow improvements, mitigating platform-specific risks and improving general stability and maintainability of Temple Wallet by building defense-in-depth protections.
Findings Summary
| Findings area | High | Medium | Low |
|---|---|---|---|
| Software design | 4 | 6 | 3 |
| Cryptography | 2 | 3 | 3 |
| Application security | 3 | 3 | 8 |
| Platform security | 0 | 1 | 3 |
| Code quality | 0 | 2 | 2 |
| Infrastructure | 0 | 2 | 1 |
| Supply chain risks | 0 | 1 | 0 |
The findings with all levels of severity have been reported, since many low-priority ones may become stepping stones in multi-step attacks.
Methodology
Cossack Labs’ review has consisted of:
- General risk model clarification and security review.
- Research of fundamental issues of cryptocurrencies in the context of interacting with wallets.
- Design/architecture review.
- Cryptographic design and implementation review.
- Application security: ensuring that application-level security controls are implemented well.
Conclusion
Our general conclusion is that the set of security controls implemented by the Madfish team can achieve the security claims and prevent risk to a satisfactory degree. However, web extension applications operate in a risky environment – their security relies on the browser security and security of the user machine. “Hot” non-custodial wallets require operational safety – users are responsible for safely storing mnemonics and keys of their accounts. This report evaluates the implementation of Temple Wallet web extension, application architecture, theoretical and practical concerns.