WalletScrutiny on Nostr: The ByBit Hack Report [1] reveals interesting details. While many blame ETH and its ...
The ByBit Hack Report [1] reveals interesting details.
While many blame ETH and its complexities, it's important to note that a combination of circumstances made this attack possible.
But the core issue clearly was a central point of failure. Multi Signature was used but all signers used the same hacked, remote server.
The server was trusted, supposedly running a well audited open source web wallet software but "open source" is not enough as the source run on that compromised server did not match the well audited code.
At WalletScrutiny we so far do not list web wallets because it is hard if not impossible to attest to the integrity of web wallet code when the server can serve different code every other second or depending on your IP address.
We are investigating options to list progressive web apps that give the user more control of what is being run. While standard PWA manifests primarily contain metadata, a security-focused implementation could leverage several mechanisms to establish stronger integrity guarantees:
Extending manifest files with cryptographic commitments to all resources
Implementing Subresource Integrity (SRI) checks to verify each script matches expected hashes
Using a trust-on-first-use (TOFU) signature model where developer keys are stored after initial verification
Creating transparent, user-controlled update processes that display cryptographic verification before applying changes
Such an approach would significantly reduce trust requirements in the server after initial installation, as the PWA could verify the integrity of updates against developer signatures before execution. Static analysis could also differentiate between PWAs with secure update mechanisms versus those with silent automatic updates.
While not eliminating all risks, this model would provide a more verifiable path than traditional web wallets, potentially bringing them closer to the verification standards we apply to other wallet types.
[1] https://docsend.com/view/s/rmdi832mpt8u93s7
While many blame ETH and its complexities, it's important to note that a combination of circumstances made this attack possible.
But the core issue clearly was a central point of failure. Multi Signature was used but all signers used the same hacked, remote server.
The server was trusted, supposedly running a well audited open source web wallet software but "open source" is not enough as the source run on that compromised server did not match the well audited code.
At WalletScrutiny we so far do not list web wallets because it is hard if not impossible to attest to the integrity of web wallet code when the server can serve different code every other second or depending on your IP address.
We are investigating options to list progressive web apps that give the user more control of what is being run. While standard PWA manifests primarily contain metadata, a security-focused implementation could leverage several mechanisms to establish stronger integrity guarantees:
Extending manifest files with cryptographic commitments to all resources
Implementing Subresource Integrity (SRI) checks to verify each script matches expected hashes
Using a trust-on-first-use (TOFU) signature model where developer keys are stored after initial verification
Creating transparent, user-controlled update processes that display cryptographic verification before applying changes
Such an approach would significantly reduce trust requirements in the server after initial installation, as the PWA could verify the integrity of updates against developer signatures before execution. Static analysis could also differentiate between PWAs with secure update mechanisms versus those with silent automatic updates.
While not eliminating all risks, this model would provide a more verifiable path than traditional web wallets, potentially bringing them closer to the verification standards we apply to other wallet types.
[1] https://docsend.com/view/s/rmdi832mpt8u93s7