The recent WebCrypto API can generate private/public keys. To prevent the private key to be extractable with JavaScript, the CryptoKey object could be stored like this in IndexedDB.

I suppose if we store it like that, a malware could read it easily, it's surely why the WebCrypto API can wrap the key with another key, so that the private key can be stored in IndexedDB encrypted. The wrapping key is stored on the server side and sent to the client after a successful authentification.

So, if the browser is closed, the malware should be able to get the private key but it's encrypted and in theory useless (excepted for brute-force attack).

But if the browser is opened, and the user log in, the server send the secret key to unwrap the private key. So at this moment, is it possible for a malware to read the network trafic, RAM, files, caches, to read/extract the unencrypted private key?

About the network trafic, I assume it's all in HTTPS, TLS 1.2 minimum with robust cipher suite, with HSTS set to max age including sub-domains, and with HPKP to prevent MITM attacks.

4 Answers 4


Extremely intelligent malware with root permissions (on a *nix client) can do just about anything, including redirecting /dev/random or /dev/urandom to something they control. If the malware can control the random number generation your computer uses to create TLS keys, then it can break the HTTPS communication.

If the browser is open and the user logged in, then malware with the ability to perform raw mem dumps would be able to find the key.

In short, if a user can do it, then a theoretical malware program can do it.

I suggest the question should not be is it possible for malware to... as malware with unrestricted power can do anything that you can do. Instead, the question is, what would it take for malware to...? From this perspective, we're not measuring what's possible, but what is probable.

The methodology you described sounds about as good as it can get (outside of using the user's password to lock the private key / shared secret so that the server doesn't have to receive, store, and transmit it). There is no such thing as perfect security.

  • Thanks for your answer! About the secret key for wrappring the private key, I said it's sent from the server, to prevent brute-force in the client side, I assume it's better to detect/reduce brute-force attacks from the server side.
    – lakano
    Oct 21, 2017 at 16:30
  • @lakano that's a dangerous presumption. If keys are stored server-side then the server becomes a single point of failure (SPOF) - you get into the server and you get everything for everyone. If the client holds their own key, server compromise is no longer a SPOF. That doesn't mean it's somehow bad that the server sends the key, just that there are pros and cons to both methods, so presuming one is better is dangerous when it comes to security.
    – cegfault
    Oct 22, 2017 at 7:32
  • @lakano P.S. a brute force attack against a good cipher is currently not computationally possible (that is, if the attacker is using a brute-force method to crack the key, it will take - literally - trillions of years). It's simply not a realistic concern. Real-world threats are not brute force attacks, but ransomware, spyware, malware, viruses; that is, you should be more concerned about things that destroy or steal data, dump memory to get access to the raw key, perform a man in the middle attack to steal the key as it transmits from server to client, etc. Not brute force attacks.
    – cegfault
    Oct 22, 2017 at 7:36
  • It's not a SPOF because the attacker also need to get access to the private key of each user's browser. If I follow your advice to use the user password for the wrapKey, this mean any javascript coder could open the victim browser on the site, open the JS Console, and try some possibles password then the WebCrypto will directly return success when it's the good password. If the wrapKey is random and sent by the server, this attack could be detected/reduced.
    – lakano
    Oct 22, 2017 at 9:07
  • 1
    @dandavis WebCrypto deriving a key only works on ECDH & PBKDF2 (other algorithm are not recommanded). And ECDH / PBKDF2 don't have sign/verify feature. ( check the Live API Table for details: diafygi.github.io/webcrypto-examples )
    – lakano
    Oct 23, 2017 at 10:24

It depends on the computer, operating system and user agent running the Javascript and the website. If either of those is compromised, then malware can get the information sent by the server to te client. For example XSS attacks can compromise the website, and the browser vendor can in theory impersonate you on any website, you are just trusting their software not to let them do it.

So yes, this is about as good as you can get. The more keys are required, the better.

The problem is, lakano, once a stored key is unwrapped in Web Crypto, I don’t think there is a way to mark the result as “non extractable”. I wish there would be a way to combine wrapping and “non extractable” keys. Have you found a way?

I have been asking for a year and no one really knows: https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5


You can store the user's private key in a CryptoKey object, with the .extractable property set to false, then store the CryptoKey object in IndexedDB storage. This way, the private key can only be used for decrypting and/or signing messages within the browser, but the private key cannot be by read client-side scripting running in the browser.



WebCrypto only helps to "identify" you. You can use it for client-certificate of a TLS session for identity, but also for "signing documents" (but that's also about identity). It does not add encryption strength, nor does its adoption prevent malware attack.

TLS encryption with just the usual server-side key prevents malware attack already. It prevents a Man-In-The-Middle injection of javascript could exploit a vulnerability in your machine, and gaining root/admin rights.

Note: this isn't the only way to compromise your machine. This isn't the place to exhaustively list the attack vectors. But it's important to note, that a determined powerful (with money, time, access) adversary will eventually compromise your machine.

If your machine is compromised, you don't need to be worrying about the privacy of your WebCrypto key. They can see everything you type on your keyboard, all of your files, install a fake Certificate Authority and decrypt all of your internet communication, watch you if you have a laptop webcam, and more.

In conclusion, you should have WebCrypto for the right reasons (identity), and use along with other strategies to minimize your risk,impact, and duration of compromise.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .