7 ms·

To address the comments about client-side JavaScript encryption being insecure, client-side JavaScript isn't inherently insecure, or rather security is entirely

To address the comments about client-side JavaScript encryption being insecure, client-side JavaScript isn't inherently insecure, or rather security is entirely dependent on the threat vectors you are trying to protect against. Some examples of levels of security: SSL/TLS: Without transport level security (SSL/TLS), and no other encryption, it is absolutely trivial to intercept data. Unsecured WiFi, malicious network operators, hacked middlemen, spoofed DNS; there are many threat vectors. Adding SSL/TLS significantly increases security. Server-side encryption: Added server-side encryption to SSL/TLS marginally increases security. It actually doesn't protect from much. Disposal of the hard drives is a common one people cite, in case HDDs aren't wiped when sent to the junk yard or for RMA. It could also protect against some accidental data leaks if files become readable through unintended means, or if the server is actually hosting the files in a third-party service (e.g., CDN, S3). It doesn't protect from employees of the server host, and it does little to protect from hackers that get full server access as the decryption key is likely stored in a file on the server. Client-side JavaScript: JavaScript encryption actually adds a reasonable amount of security. Yes, you have to trust the browser makers, the browser update mechanism, and the company hosting the service (they could always change the JavaScript to steal your password). It does make it less trivial for a malicious employee to access your data, they would have to write and deploy new JavaScript. It also makes it less trivial for a hacker that gains server access, they would have to modify the JavaScript too. Modifying the JS is feasible for a targeted attack. It also protects against offline attacks, where a hacker copies data to their own systems to analyze before they get detected. I think you have to trust the browser makers and their update mechanisms. The browsers always have access to everything, they could be capturing your banking passwords, or insert dummy SSL CAs, they could do anything. You also have to trust the makers of client software, whether it's JavaScript in the browser or C on the command-line, very few people are going to check the source code, most people will accept whatever client updates are provided. Where client-side JavaScript falls apart is that it is vulnerable to some of the most common security exploits. Namely random browser vulnerabilities, XSS attacks, and malicious or vulnerable browser extensions and plugins. People are far too willing to install or unwittingly install (thanks InstallMonetizer) browser extensions and plug-ins which have too much access to your browser data. But your bank account is also vulnerable to the same issues. So while you shouldn't use client-side JavaScript to protect Top Secret government information, it does provide a decent amount of security, and is probably good enough for most cloud storage solutions.

deleted 14y ago
[deleted]
- antoncohen 14y ago
  > Either your system provides security, or it provides no security. It's not an "amount" of security. Once you're compromised, you've lost. It's not that simple. Yes, once you are compromised that's the end of it. But security is about preventing getting compromised. There are many ways to get compromised, and different ways to mitigate the attacks. If security was that black and white (security or no security) we would all have to use air-gap networks. There would be no internet, no REST APIs, no trusted SSL CAs, we wouldn't be able to use anything. For convenience we accept a certain amount of security risk. The risk we accept, and the security measures we take, are entirely dependent on the sensitivity of the data and the threats we expect to deal with. If the NSA and CIA are after you, nothing is secure, they can physically break in and steal your systems, they have world class cryptographers and a stockpile of zero-day attacks to create trojans with. But for most of us you don't have to worry about the NSA coming after us. We don't even have to worry about highly targeted attacks from criminal gangs. Average people have to worry about semi-automated attacks to scam money out of them, steal their identity, or grab naked pictures. It's likely way easier to break into your corporate network than it is to hack a cloud storage provider and replace their JavaScript code. I recommend you read some of Bruce Schneier's essays and posts, here is good start: http://www.schneier.com/essay-319.html http://www.schneier.com/essay-319.html
7952 14y ago
What if you host the javascript separately to the dynamic content (say on S3)? This would give users some protection against compromised servers. This is akin to having an app supplied from a trusted source (ITunes) and then accessing an API through client side encryption.

deleted 14y ago

[deleted]

antoncohen 14y ago
> Either your system provides security, or it provides no security. It's not an "amount" of security. Once you're compromised, you've lost. It's not that simple. Yes, once you are compromised that's the end of it. But security is about preventing getting compromised. There are many ways to get compromised, and different ways to mitigate the attacks. If security was that black and white (security or no security) we would all have to use air-gap networks. There would be no internet, no REST APIs, no trusted SSL CAs, we wouldn't be able to use anything. For convenience we accept a certain amount of security risk. The risk we accept, and the security measures we take, are entirely dependent on the sensitivity of the data and the threats we expect to deal with. If the NSA and CIA are after you, nothing is secure, they can physically break in and steal your systems, they have world class cryptographers and a stockpile of zero-day attacks to create trojans with. But for most of us you don't have to worry about the NSA coming after us. We don't even have to worry about highly targeted attacks from criminal gangs. Average people have to worry about semi-automated attacks to scam money out of them, steal their identity, or grab naked pictures. It's likely way easier to break into your corporate network than it is to hack a cloud storage provider and replace their JavaScript code. I recommend you read some of Bruce Schneier's essays and posts, here is good start: http://www.schneier.com/essay-319.html http://www.schneier.com/essay-319.html

7952 14y ago

What if you host the javascript separately to the dynamic content (say on S3)? This would give users some protection against compromised servers. This is akin to having an app supplied from a trusted source (ITunes) and then accessing an API through client side encryption.