> ...and it maybe justified if we're gaining as much or more elsewhere.
Except that, in terms of real security, we aren't. That's the whole point. You're right in describing it in the way you did, but then you get to this point where there's this implicit assumption that JavaScript-based crypto gains you something. Which, maybe, leads into your next point...
> E.g. if we gave the user ability to store secret data without the key ever leaving his possession, he might be more likely to use the service and stop storing his secrets in a notepad file.
OK, but this is a different problem. The correct solution here is a true client-side app or a browser add-on (and even then ... ehhhh). Otherwise -- and this is a point that I don't feel like I can emphasize enough -- you are giving your users a completely false sense of security. You're selling a service by saying that "we'll store your secrets for you and you don't even have to ever give us your key, so it's more secure than keeping them in a notepad file", but that's demonstrably false.
> However if we don't guarantee that the key will not leave the user's possession, the user may decide not to use the service.
Also a different problem. You can't sell security this way. All you're doing is taking advantage of people's ignorance. If everybody understood the security risks of JavaScript-implemented crypto, and you sold the same service -- "we use JS so you never have to share your keys" -- then the users would decide not to use the service!
To reiterate:
1. Server-side encryption is a real protection from accidental or malicious data leaks (db dumps);
2. SSL is a real protection from MITM and eavesdropping (mostly, with caveats);
3. If the server software gets compromised, you're pooched no matter what.
So, again: JavaScript solves none of these problems.
The only thing that JavaScript does, is add more problems.
>You're selling a service by saying that "we'll store your secrets for you and you don't even have to ever give us your key, so it's more secure than keeping them in a notepad file", but that's demonstrably false.
Now, aren't you getting carried away? Physical loss of a laptop will compromise the notepad file, but not the client-side encrypted data. Malware on the laptop will compromise the notepad file 100%, but any crypto-based solution will only be compromised if it's been used during that time. Fire/flood/theft will deprive the user of his secrets altogether.
Seriously, are you claiming that a notepad file is more secure than a server-based storage with client or server encryption? That's an extraordinary claim.
1. That notepad file can be encrypted on the laptop; and
2. "Web app" programmers so often get security really wrong. This entire thread is just one of a huge number of examples of that.
Honestly, any hosted solution that relied on JS for encryption or authentication would encourage me to keep storing secrets in text files on my laptop.
Here's a fun, easy way to understand why hosted solutions are rarely a good idea for storing private data:
- Make a chart with four columns;
- Column 1 is "Unencrypted local storage"; column 2 is "encrypted local storage"; column 3 is "remote storage with JavaScript encryption"; column 4 is "remote storage with SSL + server-side encryption";
- Under each column, write down a list of every method you can think of that that particular system could be broken. Take your time and be creative.
- Cross out any methods that all of the columns have in common.
Except that, in terms of real security, we aren't. That's the whole point. You're right in describing it in the way you did, but then you get to this point where there's this implicit assumption that JavaScript-based crypto gains you something. Which, maybe, leads into your next point...
> E.g. if we gave the user ability to store secret data without the key ever leaving his possession, he might be more likely to use the service and stop storing his secrets in a notepad file.
OK, but this is a different problem. The correct solution here is a true client-side app or a browser add-on (and even then ... ehhhh). Otherwise -- and this is a point that I don't feel like I can emphasize enough -- you are giving your users a completely false sense of security. You're selling a service by saying that "we'll store your secrets for you and you don't even have to ever give us your key, so it's more secure than keeping them in a notepad file", but that's demonstrably false.
> However if we don't guarantee that the key will not leave the user's possession, the user may decide not to use the service.
Also a different problem. You can't sell security this way. All you're doing is taking advantage of people's ignorance. If everybody understood the security risks of JavaScript-implemented crypto, and you sold the same service -- "we use JS so you never have to share your keys" -- then the users would decide not to use the service!
To reiterate:
1. Server-side encryption is a real protection from accidental or malicious data leaks (db dumps);
2. SSL is a real protection from MITM and eavesdropping (mostly, with caveats);
3. If the server software gets compromised, you're pooched no matter what.
So, again: JavaScript solves none of these problems.
The only thing that JavaScript does, is add more problems.