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

21–30 of 63 posts

Re: Javascript encryption

#21

Post by DenisM »

tptacek wrote: post #16
antimora wrote: post #3

Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user'…

It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to impl…

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

Re: Javascript encryption

#22

Post by antihero »

tptacek wrote: post #14
gorset wrote: post #7

Earlier quoted context omitted.

If you are running javascript on a page from a server, you are trusting the server with your plaintext.

You are trusting the server, you are trusting the quality of every line of code on the server that has a hand in generating the page content (since any DOM corruption flaw will let you trivially backdoor the encryption), and you're trusting every third party server from which HTML or JS content is sourced. It's a terrible, terrible idea.

But if you wanted to, you could verify the authenticity of the code. If you're just sending plaintext off into the void, then you have zero control whatsoever. You could also open up Wireshark to verify your plaintext isn't being transmitted anywhere.

Re: Javascript encryption

#23

Post by antihero »

DenisM wrote: post #19
antimora wrote: post #3

Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user'…

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…

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

Re: Javascript encryption

#24

Post by antihero »

gorset wrote: post #7
antihero wrote: post #6

What does this offer over SJCL? And for those asking in the thread, JS encryption is useful in that you never have to trust a server with your plaintext.

If you are running javascript on a page from a server, you are trusting the server with your plaintext.

And what alternative would you suggest? An application is not acceptable.

Re: Javascript encryption

#25

Post by yid »

dublinclontarf wrote: post #9
Acorn wrote: post #8

Earlier quoted context omitted.

Seems like browser extensions would be the way to go. Here's the SJCL demo: http://bitwiseshiftleft.github.com/sjcl/demo/

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.

Re: Javascript encryption

#26

Post by tptacek »

d0ne wrote: post #20
tptacek wrote: post #15

Earlier quoted context omitted.

... which, implementing JS crypto, you should never do.

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.

Re: Javascript encryption

#27

Post by tptacek »

DenisM wrote: post #21
tptacek wrote: post #16

Earlier quoted context omitted.

It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to impl…

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

The difference between normal software and browser javascript is that browser javascript is effectively re-installed every time you visit a web page. People install new software packages less than once a week.

This is a nerdy argument I'm not particularly interested in hashing out again, so you're welcome to the last word.

Re: Javascript encryption

#28

Post by tptacek »

antihero wrote: post #22
tptacek wrote: post #14

Earlier quoted context omitted.

You are trusting the server, you are trusting the quality of every line of code on the server that has a hand in generating the page content (since any DOM corruption flaw will let you trivially backdoor the encryption), and you're trusting every third party server from which HTML or JS content is sourced. It's a terrible, terrible idea.

But if you wanted to, you could verify the authenticity of the code. If you're just sending plaintext off into the void, then you have zero control whatsoever. You could also open up Wireshark to verify your plaintext isn't being transmitted anywhere.

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. You helpfully provided them a library to do exactly that.

Re: Javascript encryption

#29

Post by xfax »

tptacek wrote: post #16
antimora wrote: post #3

Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user'…

It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to impl…

How is this any different from a XSS bug resulting in an attacker stealing the plaintext password from a form?

Also, given that the client and the server trust each other and communicate securely, doesn't this just get reduced to the probability of having these bugs and nothing more?

Re: Javascript encryption

#30

Post by xfax »

tptacek wrote: post #28
antihero wrote: post #22

Earlier quoted context omitted.

But if you wanted to, you could verify the authenticity of the code. If you're just sending plaintext off into the void, then you have zero control whatsoever. You could also open up Wireshark to verify your plaintext isn't being transmitted anywhere.

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

Post reply on HN