Should I be encrypting contents of browser / javascript memory?

Question

This is a security best practice and I'm wondering if I should even be wasting my time with this.

In the same vein of an initial crack of the Blu-ray movie format, hackers just inspected the memory of a player to snoop out a key value.

It seems like it's feasible to do the same thing with browser memory, and to look at values that the javascript interpreter has set - so should I be encrypting data that is in memory?

Thinking this through - it's eventually insane, b/c if my browser is displaying sensitive data on the screen, conceivable that piece of data is in memory and could be snooped. So it wouldnt matter if I had encrypting that same data in javascript somewhere.

I'm having a tough time explaining to my superiors of why we shouldnt go to this level of security...

Answer 1

Adam,

It's a client issue. When programming for web, browser are clients, you don't and haven't to address security issues on client side if isn't the scope of your project.

Answer 2

Really, if you are concerned with some data being in the browser, then it shouldn't be there. When data goes to the client, you can consider it compromised as you have no way of ensuring it is secure. Others have brought up a good point, you send encrypted information to the client, but you won't be able to do anything with it, because you'll have to decrypt it to show it to the end user. This is why if you look at regulations for banks, they never display any personal information (SSN etc.) on the browser, unless it was specifically typed in by the user (typed in and then posted back).

Answer 3

Don't waste your time, because it's impossible to store anything encrypted in client-side memory while displaying it decrypted. In fact, that's beyond impossible, it's flat out ludicrous!

This is why my banks web site only spits out the last four characters of my account number in the response.

Answer 4

How many desktop applications spend their time encrypting the contents of variables? It's the exact same thing.

Answer 5

The idea is that you trust the person using your application (because you're giving them access to the data) but you shouldn't be sending any more data to the client than you're willing to show them. Otherwise you get into the same kind of problems that FPS games run into with wall hacks, etc. (in order to show an enemy appear at exactly the right time when he comes running around the corner, you have to tell the client where the enemy is and what direction they're moving even if the player can't see them). You want to get away from that if possible.

You trust the user, but you certainly shouldn't trust the network, so using something like SSL between client and server makes sense.

Unfortunately you have to trust the user's platform. This is difficult. Not all browsers are created equal. Some use sandboxing which makes it a lot harder for another application on the computer (or in the same browser) to access your client data, but it's still possible. Some don't use any form of sandboxing. However, there's not much you can do because you have to decrypt your data to show it to the user.

So the best you can do is limit the data that user can see, or what actions they can do with it.

Answer 6

Your superiors are right.

You have no right to hide information on my machine from me. And luckily, it's impossible to do reliably from a technical standpoint. If you have a secret you don't trust me with, don't send it to me.