Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javascript encryption

vincentcheung.ca

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Javascript encryption

#51

Post by DenisM »

thaumaturgy wrote: post #46
DenisM wrote: post #45

Earlier quoted context omitted.

Either will work for the given scenario. The only difference I see is that with client-side crypto you can't accidentally write the key into a server log file, where as with server-side crypto it is possible. But then again at some point you will add some logging to client-side code as well, so the point will be moot - you will have to sanitize logs at point of production. Another thing is that it makes much better m…

OK, then: 1. Given that either will work for this scenario; and 2. Given that JavaScript has every weakness that the other method has; and 3. Given that JavaScript also has weaknesses that the other method does not have; then Why would you use JavaScript to solve this problem?

Why do you think the other method does not have the same weaknesses? If the browser is compromised the key that users enters into the web page is leaked, regardless of whether you use client-side or server-side crypto. The fact that in client-side crypto in addition to the encryption key the code itself could have been tampered does not add anything to the threat... does it? The key is already presumed to have been leaked, and things can not get any worse than that.

As far security is concerned, the two are equally (in)secure. And client-side crypto still has the advantage that key management is much easier to explain to the user, thus the app is more likely to be used.

Re: Javascript encryption

#52

Post by DenisM »

thaumaturgy wrote: post #48
DenisM wrote: post #47

Earlier quoted context omitted.

That's not my argument at all. My argument is that the probability of a well-designed site having XSS (p1) is much less than that of a user's machine being infested (p2). When you start using both, as you say, we end up with compound probability of a breach p1+p2, which is strictly worse than p2, but if p1 In other words, global optimization may require local pessimization. E.g. if we gave the user ability to store s…

> ...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 wit…

>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.

Re: Javascript encryption

#53

Post by thaumaturgy »

DenisM wrote: post #52
thaumaturgy wrote: post #48

Earlier quoted context omitted.

> ...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 wit…

>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…

Yes, I am making that claim.

Especially since:

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.

- Compare the results.

Re: Javascript encryption

#54

Post by thaumaturgy »

DenisM wrote: post #51
thaumaturgy wrote: post #46

Earlier quoted context omitted.

OK, then: 1. Given that either will work for this scenario; and 2. Given that JavaScript has every weakness that the other method has; and 3. Given that JavaScript also has weaknesses that the other method does not have; then Why would you use JavaScript to solve this problem?

Why do you think the other method does not have the same weaknesses? If the browser is compromised the key that users enters into the web page is leaked, regardless of whether you use client-side or server-side crypto. The fact that in client-side crypto in addition to the encryption key the code itself could have been tampered does not add anything to the threat... does it? The key is already presumed to have been l…

> Why do you think the other method does not have the same weaknesses?

Trivially: JavaScript encryption is vulnerable to MITM attacks that SSL is not. The only solution to this is to deliver your JS over SSL, but browsers will complain if you try to mix https and non-https elements in a page, and you might as well serve the whole page over https anyway. If you do that, then you still don't need JavaScript. (As one example; I know there are others but I just came in from the yard and my brain is a little melty right now.)

> As far security is concerned, the two are equally (in)secure.

This is a statement which flies in the face of the recommendations of some very smart people in the security field, some of whom have written extensive posts which have been linked to in this thread.

Even if I didn't (barely) know enough to evaluate your claims on my own, I could conclude that you might be right ... but I wouldn't bet on it.

Look, this subject has been discussed to death and nauseum, including here on HN. There have been extensive essays written about it. If you don't want to believe me, I'm OK with that. Go read their stuff, and see if it makes more sense to you.

If, after reading all of that, you still think you have some new insight in the field that everyone else has overlooked, and you can show why JavaScript is "equally (in)secure" to SSL + server-side encryption, then make your own blog post or essay about it. Make it good and in-depth, link to it from HN, tell everyone about it. I'd be happy to read it.

Otherwise you and I are just going in circles and not getting anywhere.

Re: Javascript encryption

#55

Post by danpat »

tptacek wrote: post #49
jrockway wrote: post #32

Earlier quoted context omitted.

That's true, but I'm not sure everyone should be quite so defeatist as you with respect to implementing crypto. It has and can be done, after all, it just requires care beyond "hey, my PHP script outputs some HTML." The same goes for many, many aspects of programming: design, object lifecycle, memory allocation, error handling, etc. Programming is hard, and implementing crypto is no different. The difference is that…

Where has Javascript crypto been done successfully? I'm not aware of any application with a sound use of it. There are a few narrowly-tailored experiments, all of them backed by SSL, that don't have obvious flaws. But the best-known examples, like what Meebo did a few years ago, were deployed despite glaring security flaws. No, I don't think it can-and-has-been-done.

http://www.clipperz.com/

Re: Javascript encryption

#56

Post by dublinclontarf »

yid wrote: post #25
dublinclontarf wrote: post #9

Earlier quoted context omitted.

SJCL has a bug in their RSA implementation. We're using a good bit of their code with a few changes for our web client. The idea being that we don't want to store passwords, so the webclient stores an encrpyted private key and everything sent to the server must be signed. The users id is a sha256 hash of their public key and all we keep are the public keys. Working so far in FF and Chrome, not even trying it in IE

Not sure what you mean, SJCL doesn't have an RSA implementation.

Hmmm, indeed it doesn't. Who's RSA implementation am I using, guess I've forgotten.

Re: Javascript encryption

#57

Post by dublinclontarf »

xfax wrote: post #31
dublinclontarf wrote: post #9

Earlier quoted context omitted.

SJCL has a bug in their RSA implementation. We're using a good bit of their code with a few changes for our web client. The idea being that we don't want to store passwords, so the webclient stores an encrpyted private key and everything sent to the server must be signed. The users id is a sha256 hash of their public key and all we keep are the public keys. Working so far in FF and Chrome, not even trying it in IE

Are you at liberty to disclose what you're using this for? i'm interested in learning about legitimate use cases for SJCL.

The auth system for a stock/asset exchange.

Re: Javascript encryption

#59

Post by antihero »

thaumaturgy wrote: post #40
antihero wrote: post #23

Earlier quoted context omitted.

Exactly. You can never be completely secure, but this mitigates against a large amount of potential problems.

No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more , and it offers no protection from any flaws that anything else is vulnerable to. "You can never be completely secure" is not a good justification for security theatre.

Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire.

How exactly would you implement a browser based crypto solution?

Re: Javascript encryption

#60

Post by d0ne »

tptacek wrote: post #26
d0ne wrote: post #20

Earlier quoted context omitted.

If your goal is to share state secrets, then no, I wouldn't suggest using JS for crypto. If your goal is to no longer be low hanging fruit for attackers, then yes, I would recommend it.

The terminus of your argument admits to using ROT13 as a cipher. Surely there's some attacker ROT13 bars. While you're at it, Base64 the "ciphertext". There are professional pentesters that can't recognize Base64 on sight! And if you want to get really tricksy, swap the Base64 alphabet around. That'll hoist that fruit up higher. In reality, no credible cryptosystem accepts the flaws I'm talking about.

No, it doesn't. My definition of 'low hanging fruit' means anything that can automated to the point of mass data consumption and processing within the scope of a private corporation's resources.

ROT13 clearly falls within this formula.

AES 256 client side encryption, even in JS, over a 256 bit SSL connection with 32 character base key-phrases, uniquely generated for every message, expanded into the full key and exchanged and stored in a secure fashion separate from the location of the encrypted data itself falls outside of this scope currently.

Post reply on HN