4

Today crypto libraries for JavaScript exists sjcl and hence there may be the situation that a password/key/secret/sensitivedata is stored somewhere in a variable in JavaScript.

I do not want to risk that this sensitve data is leaked/disclosed and hence I would very much like to know if there is a way to reliably wipe a variable in Javascript so that the memory used by the JavaScript Engine will not have any remaining info about he data? I would for instance not want to rely on some GC to wipe the data lazily etc.

An answer might feature an example code that kills/wipes a variable and also an explanation when (and if there are differences on what JavaScript implementation Browsers type /Nodejs) it makes sence to trust that the data has been deleted?

Else if the task is impossible I would appreciate a explanation why this is so as well and also accept this as an answer

The goal is not to protect the webpage user from accessing the script variable (this cannot be done I guess). The goal is more to guarantee that the memory of the javascript engine does not keep shadow/cached copies of the data, after the point necessary. I do want to have the data be gone so that no-one (attacker software) can get the secret data via looking at the memory been associated with the Javascript Variables.

humanityANDpeace
  • 4,350
  • 3
  • 37
  • 63
  • http://stackoverflow.com/questions/1596782/how-to-unset-a-javascript-variable – Duniyadnd Apr 24 '14 at 10:47
  • @Duniyadnd thanks, the quesiton already feature to some extend what I inquire here. I yet see the difference that this quesiton inquires about how the data is wiped from memory and not only from JavaScript accessible memory. I want to overwrite the data not make it hard to access. I want the data out of caching – humanityANDpeace Apr 24 '14 at 10:50
  • 1
    No, there is none. There is a variant called SES (Secure ECMAScript) that gives you these sort of guarantees (Mark Miller has interesting papers about it you should read). Not in browsers sadly. no. – Benjamin Gruenbaum Apr 24 '14 at 10:51
  • The problem with this is what it's possible to debug JavaScript in browsers like Chrome, and step through the code as it runs. There's nothing you could do to prevent a user from obtaining a variable's content prior to it being deleted. – James Donnelly Apr 24 '14 at 10:51
  • The second question is - who are you hiding this data from? The user knows the secret/key/sensitive data anyway. This is no different from _any other_ client app (like desktop applications). The main difference and the problem is that until we have CSP in, and a way to opt out of extensions for a website. An extension can always try to cheat you, and it has better hooks. For example, it can override `Function.prototype.call` and thus override any attempts to use closures for this sort of thing. – Benjamin Gruenbaum Apr 24 '14 at 10:53
  • @BenjaminGruenbaum thanks for the enriching comments. Maybe they can be phrased in a response. I think you could cover it and it would be clearer for later users (instead of the comments). Anyway I do want to hide it from other software that runs later. I do not want to hide it form the user. Yet other software of the user might not be trusted and I would protect the user by not leaking the info into memory – humanityANDpeace Apr 24 '14 at 10:54
  • @JamesDonnelly I am aware that the user (via debug/browser) can get the data. I do not want to prevent this though, as the user is the one that supplied the data anyways. To be clear: I do not want the data to stay stuck/cached somewhere in memory so it might be exposed to other code then that of my website. – humanityANDpeace Apr 24 '14 at 10:57

1 Answers1

2

JavaScript is garbage collected. In addition, there is no mechanism for deterministic resource management built in. You can make one, but the resource would have to be external.

Even if you build such a mechanism (with a C++ external module in Node for example), engines don't give you strong guarantees on when their copy of the memory is cleared. You would have to manually assign to the same variable parts of the resource data and replace it with junk yourself. That would likely work but there is still no guarantee at the engine level.

This is simply not a problem JavaScript implementations are built to do well at this point. There is no SecureString. That said - smart people are working on variants of ECMAScript (the JS standard) that give you much stronger guarantees. That's a good first step towards addressing the problem (but no such guarantee yet).

I don't even want to get started on browsers, where browser extensions can easily get better hooks than you and write over Function.prototype.call and hook on every function call, JavaScript has quite powerful AOP capabilities built in, for worse in this instance.

One possible solution would be to run the whole program within a VM that uses encrypted RAM, but I'm against rolling your own crypto like that. Generally, an attacker should not have access to your program's RAM in the first place, if they do, they can install a browser extension :)

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504