He compromised the wallet by getting the user to (willingly) compromise the "OS" under which the wallet runs (aka the browser) by means of installing a malicious extension.
Every single software-based wallet will be vulnerable to this sort of environment compromise.
His claims is that local storage is bad for key storage, but what are the other options for a browser-based wallet? The proper alternative is to not have browser-based wallets, but if you must have one, then local storage seems fine?
The wallet makers could have required a password and encrypted the data going into localstorage. But then there would be no way to recover that key if the password was ever lost.
Even with encryption, LocalStorage is not a safe place to store sensitive data though. What if the user clears their browser data?
As an aside: Wallet key management and recovery is one of the biggest issues with web3. Either the UX is great but your keys are in the developer's cloud and protected by password + MFA like everything else or your keys are local-only either encrypted with an unrecoverable password or not encrypted at all.
> The wallet makers could have required a password and encrypted the data going into localstorage.
How would users enter the password (on a website) without exposing it to attackers?
If you have a malicious extension installed in your browser, it's game over: No website you visit will be safe.
To be precise: Technically, only every site you grant the extension access to is compromised – but the default for extensions all too often is "every site", so users are trained to grant that pretty freely for extensions they consider useful...
I think this is a vulnerability. Sensitive browser extensions needs to consider malicious extensions in their threat model the same way that mobile apps need to consider malicious apps on the same device, etc.
I'm not sure there's an out of the box mechanism for this, but imo if this is a risk to your extension, then you as the developer should have a mitigation for it.
I don't think the extension itself was even attacked here. It seems like the wallet credentials were stored in the localStorage of some website, which the (legitimate) extension can access, but a malicious one can as well.
Update: It seems like there is no legitimate extension after all. The "attack" is just exfiltrating keys stored on some website's localStorage.
That's arguably not even an attack, just the browser extension security model working as designed....
I just re-read the article – there is no sensitive browser extension here, just a pure webapp.
I wonder if the project will keep paying $1000 (begging the quesiton if that's denominated in USD or tokens "worth $1000"?) to everybody pointing out that pretty well-understood fact about the browser/extension security model to them?
10 comments
[ 2.9 ms ] story [ 41.7 ms ] threadHe compromised the wallet by getting the user to (willingly) compromise the "OS" under which the wallet runs (aka the browser) by means of installing a malicious extension.
Every single software-based wallet will be vulnerable to this sort of environment compromise.
His claims is that local storage is bad for key storage, but what are the other options for a browser-based wallet? The proper alternative is to not have browser-based wallets, but if you must have one, then local storage seems fine?
Even with encryption, LocalStorage is not a safe place to store sensitive data though. What if the user clears their browser data?
As an aside: Wallet key management and recovery is one of the biggest issues with web3. Either the UX is great but your keys are in the developer's cloud and protected by password + MFA like everything else or your keys are local-only either encrypted with an unrecoverable password or not encrypted at all.
How would users enter the password (on a website) without exposing it to attackers?
If you have a malicious extension installed in your browser, it's game over: No website you visit will be safe.
To be precise: Technically, only every site you grant the extension access to is compromised – but the default for extensions all too often is "every site", so users are trained to grant that pretty freely for extensions they consider useful...
I would hope so, but I'm not familiar with the APIs.
Update: It seems like there is no legitimate extension after all. The "attack" is just exfiltrating keys stored on some website's localStorage.
That's arguably not even an attack, just the browser extension security model working as designed....
I wonder if the project will keep paying $1000 (begging the quesiton if that's denominated in USD or tokens "worth $1000"?) to everybody pointing out that pretty well-understood fact about the browser/extension security model to them?