Key management
Security
JavaScript
Blog posts
go back

Why you should NEVER handle private keys in the browser

Please, separate key management from your UI

November 1, 2023
written by
Fraser Brown
Co-Founder & CTO
Deian Stefan
Co-Founder & Chief Scientist
tags
Key management
Security
JavaScript
Blog posts
Browser-based wallets let users fire up Chrome, log in to a website, and start trading crypto or buying NFTs within seconds. There’s a serious cost to this convenience, though: every browser-based wallet transaction requires _signing with secret keys in the browser_—and, as a result, potentially exposing keys to hackers. Though browser-based wallets and other, safer wallets both present browser interfaces, safer wallets sign transactions far away from attackers (e.g., in secure hardware), while browser-based wallets do everything browser-side, pulling plaintext secret keys directly _and dangerously_ into browser memory.<br> <br> Attackers love it when secret keys are exposed in plain text in the browser, and the most straightforward way to steal exposed keys is by phishing for them. Attackers can trick you into revealing your browser-based wallet credentials, use your credentials to access your wallet, prompt the wallet to reveal your plaintext keys, and then buy NFTs to their heart’s content. The _art_ is in getting you to give up your login information. Some attackers send emails warning that you must reset your password in twenty-four hours, using the following convenient link, OR ELSE. Others impersonate your boss via text message, or develop relationships over email for many months before asking you (sweetly!) for your username and password.<br> <br> The good news is that, with eagle eyes for scam emails and the help of <a href="https://www.yubico.com/why-yubico/for-individuals/" target="_blank">two-factor</a> <a href="https://support.google.com/accounts/answer/1066447" target="_blank">authentication</a>, you can protect yourself from (<a href="https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/" target="_blank">most</a>) phishing attacks. The _bad_ news is that other kinds of attacks on browser-based wallets are beyond the scope of your control. Sophisticated attackers—or attackers targeting <a href="https://www.coinbase.com/blog/responding-to-firefox-0-days-in-the-wild#" target="_blank">sophisticated users</a>—can skip phishing entirely and steal keys using operating system or browser vulnerabilities. These bugs have nothing to do with you, but if a good browser developer is having a bad day and mistypes a single number, you and your crypto could be collateral damage.<br> <br> These attacks <a href="https://googleprojectzero.github.io/0days-in-the-wild/rca.html" target="_blank">actually happen</a>: browser vendors routinely announce fixes for bugs they warn are being “exploited in the wild” (by someone, somewhere, probably relaxing in the comfort of their own living room). One class of bugs, called “memory safety” vulnerabilities, let attackers manipulate browser memory into revealing your keys; others let attackers modify seemingly safe webpage content, slipping in scripts that send keys to their own servers.<br> <br> Even if attackers struggle to exploit your browser and can’t exploit you, they can still attack the browser-based wallet itself. Browser wallet code is at a disadvantage because it’s almost always written in JavaScript, a language that’s <a href="https://www.destroyallsoftware.com/talks/wat" target="_blank">delightfully quirky</a> or downright dangerous, depending on who you ask. If you ask cryptographers, they’ll say “dangerous.” That’s because writing safe cryptographic code requires fine-grained control over _how_ that code executes—and JavaScript makes such fine-grained control almost impossible.<br> <br> Instead of leaving code execution in control of the programmer, JavaScript code executes on top of a special-purpose piece of software called a JavaScript engine, which plays all kinds of tricks in the name of speed (as opposed to safety). It may indiscriminately replicate your keys, or leave your secrets strewn about long after they’re useful, or even optimize in ways that inadvertently reveal _entire_ secret keys through seemingly benign differences in the timing of operations. Writing secure cryptographic code in JavaScript is almost impossible, so it’s safe to assume that browser-based wallets are…unsafe.<br> <br> You _could_ audit browser-based wallets’ crypto code, become an expert in browser vulnerability detection, update your browser constantly, detect every misspelled login link, and on and on. While devoting your life to auditing wallets this way is completely unreasonable, it’s also almost certain to fail, since a single mistake is enough to compromise your keys. When that mistake leads to an attack against you, your browser, or your browser-based wallet, you’re out of luck: there’s no MasterCard support line that will freeze your Eth wallet and issue you a new one. To protect yourself from predictable danger, _just avoid browser-based wallets altogether_.<br> <br>

Read more

What's embedded in your embedded wallet?

What's embedded in your embedded wallet?

Here are the four questions to ask before choosing your embedded wallet provider. If you want to keep your users’ keys safe—and keep yourself safe from key custody risk—read on.

May 6, 2024
Cubist joins the Allora Network as a node operator

Cubist joins the Allora Network as a node operator

As a node operator, Cubist is supporting Allora’s mission by operating a validator to secure the Allora chain and a Reputer to rate the performance of the ML models delivered by Allora Workers.

April 15, 2024
Slashing risks you need to think about when restaking

Slashing risks you need to think about when restaking

A proper anti-slashing setup mitigates these risks on AVSes which have designed their protocols to be anti-slashable, but this doesn’t mean just firing up an instance of Web3Signer.

March 28, 2024