I didn't mean client has to be hacked but did mean script from compromised server has to run on client to decrypt user data. Hacker has to compromise the server then, for each connecting user, serve malware javascript.
Meanwhile, external network of monitors, masquerading as real users, detect that server is compromised and alert the admins who can take appropriate actions. Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected.
Or the connection in between, unless SSL is satisfying that part of our threat model.
then, for each connecting user, serve malware javascript.
No problem there, that's a core function of a server. It's a feature of MitM tools as well.
What's more difficult is an attacker who wants to target only a few specific users.
Meanwhile, external network of monitors, masquerading as real users,
A nice idea, let me know when you get that implemented.
detect that server is compromised and alert the admins who can take appropriate actions.
That's always a fun conversation to have. Be prepared for denial, anger, bargaining, and depression before getting to acceptance.
Monitor network: "We've found sometimes users are receiving the old version of the Javascript, you know, the buggy one? Particularly when certain key words like 'democracy' occur in the text."
Site operator: "Oh, must be an old file on one of the servers."
Monitor network: "We think it might be a targeted attack"
Site operator: "Well, what are the chances of that"
Monitor network: "This is not a random phenomenon like earthquakes"
Site operator: "But, you can't prove it, and not all users are affected, right?"
...and so on
Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected.
This scheme should not be confused with actual security.
How does this not add to security?
More moving parts to break and make things worse. Every bit of script and supplemental page content is another weakest link.
And they will break, because they're being developed by those who are ether don't understand or are not willing to admit that they're pushing snake oil, even after the systemic flaws in their scheme have been pointed out repeatedly.
> Or the connection in between, unless SSL is satisfying that part of our threat model.
From my original comment: "With HTTPS."
> A nice idea, let me know when you get that implemented.
It's part of a service I'm currently previewing privately.
One of the projects I worked on was a sophisticated fraud-detection framework which was deployed to one of the largest banks and acquired by a top security company. Stuff like this is not easy to implement and work never ends but then that's why we get paid.
I could see it working well enough for banks. But banks are an unusual scenario. They (and maybe insurance companies) are the only businesses that have become accustomed to having so much loss due to fraud that they can handle it as aggregate risk and a cost of business.
for each connecting user, serve malware javascript.
For most web servers, this involves replacing a file. And since your attacker can just go to the page with crypto JS to receive the "clean" version, s/he can prepare the malware JS in advance.
Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected.
How does this not add to security?
Oh, it adds to security. For the length of time between compromise and a replaced JS file. As noted above, s/he can easily rewrite your JS appropriately before entry, in which case you've got about a minute or two of extra safety.
If you assume you can detect any compromise of your system within 3 minutes, then yeah, 1 or 2 minutes out of 3 is great. If you miss it, then it's a whole lot of work for barely any benefit. And assuming you can detect any compromise within 3 minutes is highly optimistic.
Any malware script served to users will also be served to monitors and compromise is just a matter of comparing hashes with originals.
Re any compromise, only detection of compromise to content/script served to client is necessary in this approach. In extreme case, public read-access to most of the server might even be plausible (although not advisable) IMO.
And when China hacks your server, takes a little bit longer, and inserts a rule that only serves the malware JS to Chinese-allocated IPs, will your monitor systems be checking from mainland China, too?
Maybe they don't modify your app's code, but insert an iptables rule that achieves the same effect.
When a scheme relies on perfect intrusion detection you are not discussing security, you're discussing damage control.
There are safety measures one has take to deploy stuff I describe to protect against subset attacks like you mentioned as well as hackers using sleepers or logs to identify monitors, etc. It's not easy stuff and definitely not something startups should take on w/o getting side-tracked.
This is why I wrote "when applied appropriately" in my original comment.
Meanwhile, external network of monitors, masquerading as real users, detect that server is compromised and alert the admins who can take appropriate actions. Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected.
How does this not add to security?