How dangerous is JavaScript cryptography?

[Man]

Every few years, security experts start discussing the harm of JS cryptography. Now they have resumed. What was the reason and why do some experts have such a prejudice against cryptographic operations in the browser? Let's try to figure it out.

Critique of JavaScript Cryptography​

Claims about browser cryptography are centered around the following points:

• Excessive use of JS crypto functions where SSL/TLS is sufficient. For example, creating custom crypto protocols to transmit password hashes from the client to the server during authentication. Or generating an AES key for each user note on the server so that encrypted data is not accessible to anyone else, not even the server.
• Transferring JS code to the browser cannot be done securely if the server is not trusted (the chicken and egg problem). In other words, if you do not trust the server to transfer the password over SSL/TLS, there is no reason to trust it to transfer the cryptographic JS code to the client. The same attacker who can potentially intercept passwords before SSL/TLS encryption can also compromise the JS code, which is very easy to do by injecting a single script. Of course, crypto libraries can be transferred over SSL/TLS, but in this case they are no longer needed.
• Browser JavaScript is not designed for cryptography, to the point that it is allegedly inherently hostile to information security applications, it has too many "simple" vulnerabilities. Of course, vulnerabilities are also found in serious cryptographic software and libraries, but these are isolated rare cases. Finding such vulnerabilities takes a lot of effort and time, while bugs in JS code can be trivial.
• False sense of security: The use of weak JS cryptography discourages users from using truly high-quality and secure cryptographic tools.

The complaints are specifically about cryptographic operations in the browser, while executing cryptographic JS code outside the browser is not considered so dangerous/wrong.

According to critics, browsers do not provide a stable execution environment, and various code is transferred to the browser as the page loads and on individual events such as mouse hover. Thus, it is impossible to guarantee the security of JS cryptography without guarantees of the security of the rest of the content that is loaded along with it. For example, a backdoor can hide somewhere in a foreign element of the DOM tree - and even the best JS procedure will be compromised.

A volatile execution environment means that each execution of JS code is essentially executed after its reinstallation. Neither the stability of the code itself nor the constant environment can be guaranteed.

Another problem with browsers is the total caching of all content, which does not allow the execution of cryptographic code in a clean environment.

Modern practices​

In the reality of the modern web, most cryptographic functions are already implemented in JavaScript. The main primitives of system programming necessary for cryptography are supported, including a random number generator. For example, through Math.random():

function getRandomInt(max) {
 return Math.floor(Math.random() * max);
}

console.log(getRandomInt(3));
// Expected output: 0, 1 or 2

console.log(getRandomInt(1));
// Expected output: 0

console.log(Math.random());
// Expected output: a number from 0 to <1

It must be admitted that the scope of web cryptography is gradually expanding, so that it is taken more seriously. It is becoming the subject of scientific papers, auditing of existing libraries, etc.

In the last decade, many cryptosystems have been implemented on the web, including applications with end-to-end encryption, P2P systems with secret sharing, financial systems on the blockchain, zero-knowledge proof protocols (ZKP). A sniffer-resistant password authentication protocol (SRP) based on the PAKE key exchange and other systems have been developed, including those whose security has been mathematically proven. All of them rely on JS cryptography in the browser and consider it normal. Although critics call it cryptographic theater (by analogy with security theater, where only the illusion of security exists).

In the end, downloading code from a server is not much different from downloading software packages from a repository. These channels have the same protection method - HTTPS:

"If [the package manager] supports HTTPS and properly validates certificates, the distribution can install repositories or mirrors that support HTTPS communication. This will not protect against a malicious mirror, but it will prevent a MiTM attack from an unauthorized party." — from "Looking in the Mirror: Attacks on Package Managers", CCS '08: Proceedings of the 15th ACM conference on Computer and communications security, pp. 565–574, doi: 10.1145/1455770.1455841

The PGP ecosystem is considered as an alternative to web cryptography, which is free of all the shortcomings of browsers, providing a stable and reliable execution environment for cryptographic functions. However, PGP has its own shortcomings that prevent this ecosystem from growing its audience.

In addition to PGP, there are many other cryptographic tools that are distributed with open source code and are quite stable. Password managers, programs for encrypting messages, files and hard drives, instant messengers, etc. These tools are isolated from the volatile browser environment.

In fact, there is no unambiguous answer to the question of the security of web cryptography. In some cases, web applications with cryptography support are safer than similar native applications without cryptography.

Source