3 ms·

Having a server compromised is bad. Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every use

Having a server compromised is bad. Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? That said, the key for security is to design an app where compromising the server isn't possible.

nwh 13y ago
> Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? I would say that the latter is far more severe. People are going to be a lot more complacent when they believe that the data they are storing can't be accessed by others, or is otherwise immune to attacks. There's also the distinct possibility that the user is going to be storing sensitive information that they wouldn't normally store anywhere but locally. Don't get me wrong, I love encryption, I just get uneasy around browser implementations. There's some very fragile ones in use at the moment (see mega.co.nz, blockchain.info).
- absherwin 13y ago
  I'm uncomfortable with arguments that are equivalent to PerceivedBenefit(X)>RealBenefit(X) and RealBenefit(X)>0 but NegativeBenefit(Actions|PerceivedBenefit(X))>RealBenefit(X) so X should be banned. Since PerceivedBenefit(X) and Actions will both vary by individual and are controllable through learning and discipline, I'd rather give individuals the right to choose. Equivalent examples: Seatbelts are bad since people will drive recklessly; calculators are bad since people won't bother learning arithmetic; cars are bad since people will walk less. In each case, the negative does occur. I'd argue that as a whole society is better for all of those.
rosser 13y ago
That said, the key for security is to design an app where compromising the server isn't possible. That's simply not possible. There's always an exploit somewhere. Continually kicking the can of security "upstream" and being confident that your stuff is secure so long as no-one else messes up is naïve and myopic.
- absherwin 13y ago
  In that case is it possible to design a secure application? Can you design an application used by real world people that will remain secure even if the infrastructure that controls it is taken over? If a server is taken over, the best one can hope for, is sufficiently layered defenses to limit the immediate gains of the attacker and an alarm to warn users not to trust the application until further notice.
MichaelGG 13y ago
However subtle? It's entirely transparent to the user! Even if the user is somehow checking the exact JS bytes received (which is so pointless a stretch), what if the server is already compromised the first time the user gets there? Or they're on another computer? And then, how do you deliver updates? If I compromise SSL or your server, I'll use that channel to tell people "we updated the code, it's good". How is the user supposed to determine to trust the JS in the first place? This literally boils down to strength of SSL. Create something in JS that doesn't rely on SSL, and then you'll have something to show off.
- chacham15 13y ago
  Hmmm, code-signed js would seem to fit the bill, no? I guess that fundamentally, it is still using the same CA structure that SSL is. This, however, has no solution even for compiled applications: if the servers private key is compromised then all bets are off.

nwh 13y ago

> Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? I would say that the latter is far more severe. People are going to be a lot more complacent when they believe that the data they are storing can't be accessed by others, or is otherwise immune to attacks. There's also the distinct possibility that the user is going to be storing sensitive information that they wouldn't normally store anywhere but locally. Don't get me wrong, I love encryption, I just get uneasy around browser implementations. There's some very fragile ones in use at the moment (see mega.co.nz, blockchain.info).

absherwin 13y ago
I'm uncomfortable with arguments that are equivalent to PerceivedBenefit(X)>RealBenefit(X) and RealBenefit(X)>0 but NegativeBenefit(Actions|PerceivedBenefit(X))>RealBenefit(X) so X should be banned. Since PerceivedBenefit(X) and Actions will both vary by individual and are controllable through learning and discipline, I'd rather give individuals the right to choose. Equivalent examples: Seatbelts are bad since people will drive recklessly; calculators are bad since people won't bother learning arithmetic; cars are bad since people will walk less. In each case, the negative does occur. I'd argue that as a whole society is better for all of those.

rosser 13y ago

That said, the key for security is to design an app where compromising the server isn't possible. That's simply not possible. There's always an exploit somewhere. Continually kicking the can of security "upstream" and being confident that your stuff is secure so long as no-one else messes up is naïve and myopic.

absherwin 13y ago
In that case is it possible to design a secure application? Can you design an application used by real world people that will remain secure even if the infrastructure that controls it is taken over? If a server is taken over, the best one can hope for, is sufficiently layered defenses to limit the immediate gains of the attacker and an alarm to warn users not to trust the application until further notice.

MichaelGG 13y ago

However subtle? It's entirely transparent to the user! Even if the user is somehow checking the exact JS bytes received (which is so pointless a stretch), what if the server is already compromised the first time the user gets there? Or they're on another computer? And then, how do you deliver updates? If I compromise SSL or your server, I'll use that channel to tell people "we updated the code, it's good". How is the user supposed to determine to trust the JS in the first place? This literally boils down to strength of SSL. Create something in JS that doesn't rely on SSL, and then you'll have something to show off.

chacham15 13y ago
Hmmm, code-signed js would seem to fit the bill, no? I guess that fundamentally, it is still using the same CA structure that SSL is. This, however, has no solution even for compiled applications: if the servers private key is compromised then all bets are off.