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

41–50 of 63 posts

Re: Javascript encryption

#41

Post by thaumaturgy »

xfax wrote: post #30
tptacek wrote: post #28

Earlier quoted context omitted.

How exactly are you verifying the authenticity of the code? By looking at the Javascript code? Even if you're among the 0.0000000% of users who could look at JS AES and know if it's backdoored, how do you know if any of the Javascript functions it's calling have been backdoored? Similarly: what does it matter if you can see plaintext on the wire? The attacker siphoning off your data can re-encrypt it for themselves.…

When was the last time you checked whether your compiler wasn't producing backdoored code? How about those chips on your motherboard? Perhaps an instruction or two are being executed without your consent? You are just being paranoid at this point. Like someone mentioned, using this to encrypt state secrets? Stupid idea. Using it to provide some level of trust that the server never sees the plaintext data? Pretty reas…

Why are you protecting against the server never seeing plaintext data? In case the server is compromised? If the server is compromised, then so is your JS!

The difference between traditional compilers, chips on motherboards, and so on and so forth, are that you aren't downloading and using a fresh copy every time.

If it were possible to securely store some JavaScript in your browser (trust-on-first-use), or otherwise verify that the JS hadn't changed since the last time you used it, and if that JS weren't accessible from the DOM, and if that JS were well-written and used standard practices and had been reviewed by cryptographers, then maybe it would be OK to use.

...But then again, you've just reinvented SSL.

Re: Javascript encryption

#42

Post by jrockway »

thaumaturgy wrote: post #36
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…

If there's anything I've learned so far after observing the security world for a few years, it's that implementing crypto is very different. I think that this mindset from programmers -- "crypto is just like programming" -- is what causes them to constantly, and almost without fail, screw up their password storage systems, their authentication mechanisms, their crypto functions, and pretty much everything else securi…

The reason people screw up password storage is because they don't know they are supposed to think about it. If they flipped the "oh, this is important" switch, the result would be better. But at the end of the day, their bosses are asking them for shiny widgets, not a secure backend. So they are doomed to fail.

The same goes for the non-security things I've listed. The problem is much deeper than getting crypto wrong -- most programmers today get everything wrong. That's why I think if you're the type of person that can think about programming, it's not too unsafe to implement AES in Javascript and use it. You know what the weaknesses of Javascript-based crypto are, and you know how to implement crypto. In that case, why not do it?

Remember: most non-crypto software is massively incorrect. If we can trust people to implement crypto, why can we trust them to be programmers at all?

Re: Javascript encryption

#43

Post by antimora »

dguido wrote: post #18

Relevant: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... The killer for me has always been #7 on Nate Lawson's list: Auditability. How do you tell that your browser is using the right copy of the code to do the crypto?

This is an excellent article on this subject. The author (Nate Lawson) is thorough in his argument. His conclusion is "I am certain JS crypto does not make security sense."

Re: Javascript encryption

#44

Post by thaumaturgy »

jrockway wrote: post #42
thaumaturgy wrote: post #36

Earlier quoted context omitted.

If there's anything I've learned so far after observing the security world for a few years, it's that implementing crypto is very different. I think that this mindset from programmers -- "crypto is just like programming" -- is what causes them to constantly, and almost without fail, screw up their password storage systems, their authentication mechanisms, their crypto functions, and pretty much everything else securi…

The reason people screw up password storage is because they don't know they are supposed to think about it. If they flipped the "oh, this is important" switch, the result would be better. But at the end of the day, their bosses are asking them for shiny widgets, not a secure backend. So they are doomed to fail. The same goes for the non-security things I've listed. The problem is much deeper than getting crypto wrong…

I think I see where you're coming from, but I still disagree: I've seen way too many examples of otherwise competent programmers still stuck on, for instance, the notion of using salts with fast hash functions for password storage. Hell, MtGox had a post just the other day about their all-new triple-salted SHA256 password storage! Somewhere that day, there was a faint groan from the dismally small set of people who are knowledgeable in password storage and are interested enough in Bitcoin to have read about that.

The difference between bugs in non-crypto software and bugs in crypto software is that bugs in crypto software can have much more severe and far-reaching consequences. So, while I might trust a programmer to write decent non-crypto software, I would prefer not to trust them with writing crypto software.

edit: actually, there's more to it than that, on second thought. Crypto also requires a greater depth and breadth of expertise. The math knowledge required for general programming is trivial by comparison; about the worst it usually gets is vector-based math, or simple calculus, or big-O notation. But to understand crypto well enough to implement it correctly requires a much greater knowledge of mathematics -- something which most programmers don't have.

> You know what the weaknesses of Javascript-based crypto are, and you know how to implement crypto. In that case, why not do it?

Because I (the rhetorical "I" in this case) know what the weaknesses of JavaScript-based crypto are. :-)

Re: Javascript encryption

#45

Post by DenisM »

thaumaturgy wrote: post #39
DenisM wrote: post #19

Earlier quoted context omitted.

Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g. equipment theft, FBI seizures, backup tape leaks), so if/when the breach happens the thieves will have made off with encrypted copy of your data. The only way your data is jeopardized is one of the two cases: 1. The people maintaining the service turned out to…

I don't follow. How is this a justification for JavaScript crypto? It might be a justification for some form of crypto, but if that's the case, why not stick with SSL + server-side encryption?

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 messaging - "the encryption key never leaves your machine".

Re: Javascript encryption

#46

Post by thaumaturgy »

DenisM wrote: post #45
thaumaturgy wrote: post #39

Earlier quoted context omitted.

I don't follow. How is this a justification for JavaScript crypto? It might be a justification for some form of crypto, but if that's the case, why not stick with SSL + server-side encryption?

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?

Re: Javascript encryption

#47

Post by DenisM »

thaumaturgy wrote: post #34
DenisM wrote: post #21

Earlier quoted context omitted.

XSS is in your own control (as a site owner/developer), and it is less likely to happen than the user machine being infested with malware to begin with. And the malware infestation threat has never stopped anyone from advocating native (non-browser) crypto, right?.

Your argument here looks like, "other things have vulnerabilities, and JavaScript has vulnerabilities, so it is equivalent to other mechanisms." If that is your argument, then the conclusion is wrong, because JavaScript implementations are vulnerable to everything that everything else is vulnerable to, and then some . There is nothing that a JavaScript implementation actually protects you from.

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 p1In other words, global optimization may require local pessimization.

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

Re: Javascript encryption

#48

Post by thaumaturgy »

DenisM wrote: post #47
thaumaturgy wrote: post #34

Earlier quoted context omitted.

Your argument here looks like, "other things have vulnerabilities, and JavaScript has vulnerabilities, so it is equivalent to other mechanisms." If that is your argument, then the conclusion is wrong, because JavaScript implementations are vulnerable to everything that everything else is vulnerable to, and then some . There is nothing that a JavaScript implementation actually protects you from.

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

Re: Javascript encryption

#49

Post by tptacek »

jrockway wrote: post #32
tptacek wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: Javascript encryption

#50

Post by tptacek »

jrockway wrote: post #42
thaumaturgy wrote: post #36

Earlier quoted context omitted.

If there's anything I've learned so far after observing the security world for a few years, it's that implementing crypto is very different. I think that this mindset from programmers -- "crypto is just like programming" -- is what causes them to constantly, and almost without fail, screw up their password storage systems, their authentication mechanisms, their crypto functions, and pretty much everything else securi…

The reason people screw up password storage is because they don't know they are supposed to think about it. If they flipped the "oh, this is important" switch, the result would be better. But at the end of the day, their bosses are asking them for shiny widgets, not a secure backend. So they are doomed to fail. The same goes for the non-security things I've listed. The problem is much deeper than getting crypto wrong…

Do you know where the weaknesses of Javascript crypto are? I'm not sure I know all of them, and I know a couple that don't have solutions that don't require browser plugins.
Post reply on HN