2

When I pass a password as a parameter to a function, I presume it will end up on a stack or heap.

When this function returns I'd expect that my password is still in memory somewhere until it is garbage collected and hopefully wiped before being freed.

What can developers do to securely wipe such parameters as soon as they are no longer needed or when function returns?

Does assigning "some string" or {dumb: "object"} to a parameter achieve this?

Anders
  • 64,406
  • 24
  • 178
  • 215
philcolbourn
  • 269
  • 2
  • 8
  • 2
    reload the frame, use a webworker you can destroy, use a shared memory buffer you can clobber, use a typed array instead of a string, or just don't worry about it. – dandavis Aug 27 '18 at 16:27
  • @dandavis It might be good to turn that into an answer. – forest Sep 01 '18 at 01:37
  • @dandavis, my app is a chrome extension and refreshing does not seem to be an option. I will look at typed arrays as that will allow me to wipe my password storage, but I presume I will still be at mercy of browser and how it destroys an extension after use. – philcolbourn Sep 02 '18 at 08:30
  • Out of curiosity, what are you attempting to defend against? Which threat exists only after you've willingly passed the plain text password about? – JᴀʏMᴇᴇ Sep 06 '18 at 15:37
  • @JayMee, threat is another program/process reading password from memory not wiped. (my ignorance abounds here) - can any process (inc. root) now read it after my popup extension has closed? I understand that while it is running there is a threat of being read as well, but I deem risk acceptable since extension popup is active for say 1 minute after user enters password. – philcolbourn Sep 10 '18 at 04:43

1 Answers1

3

Your suggesting, to overwrite by assigning a new value to the variable, will not work (at least not on any JS implementations in use in common browsers). JavaScript strings are immutable, meaning that when you assign a new value to a string variable, a new string is created somewhere on the heap. It does not overwrite the old one. Wrapping it in an object, such as in your second example, does not change this.

The garbage collector in JavaScript is abstracted away, and there is no API for you to interact with it. So you can not directly control what it does or tell it to delete a value from memory at once.

There might be some kind of clever trick/ugly hack that you can try to influence the behaviour of the GC, but I doubt it will be worth the effort. I'd recommend you to think about what threat you are trying to defend against, and consider if it's really a problem for you that the password remains in memory.

Edit: As dandavis correctly highlight in comments, there are JavaScript types that can be overwritten, e.g. typed arrays. However, you still need to get the sensitive data into one of those without it every being stored in an "ordinary" variable. If you just copy it from input.value you have gained nothing. I don't know how to do that, and honestly, I would not bother trying.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • 2
    typed arrays (ex: `Uint8Array`) don't replicate on modification; they are supposedly low-level. Not sure how useful that is for passwords but it seems to side-step your GC concerns and complicate your 1st sentence. You can wipe a Typed Array and not expect stale fragments to remain. – dandavis Sep 01 '18 at 07:20
  • @dandavis Very good point, worthy of it's own answer if you'd want to post one. Thanks! – Anders Sep 01 '18 at 09:21
  • Note that you need to think about how the sensitive data gets into the typed array. If I just copy from `event.target.value` nothing is gained. – Anders Sep 01 '18 at 09:24
  • right, the "last mile" problem is why i didn't post an answer. Such types _do_ ameliorate your technical concerns, but I didn't see how they solved OP's issue. I suppose you could load such from a File() or maybe even fetch(), but not from the DOM... – dandavis Sep 01 '18 at 17:55