5

I have a login form for a user to type his/her password. This form is bound to an AngularJS model. Suppose that in the corresponding controller the user-given password is available via $scope.password.

The actual login procedure is handled by this function call: login($scope.email, $scope.password). After that procedure the application logic does not need the password anymore and my wish is to clear it from the browser's memory.

To me, the most obvious question is: what can I do right after calling login($scope.email, $scope.password) in order to clear the memory holding the value that $scope.password is currently bound to? This question is valid for JavaScript in general, I hope.

But then, following up from here, I have two more AngularJS-specific questions:

  • Is the password form value bound to more AngularJS-internal variables than just to $scope.password? In that case, overriding $scope.password would not be helpful.

  • When switching the view, the controller corresponding to the old view and its scope become "destroyed". Should I simply rely on the garbage collection to clear the memory containing the password within a short time interval after switching away from the login view?

Dr. Jan-Philip Gehrcke
  • 33,287
  • 14
  • 85
  • 130
  • 2
    What is the problem that you're trying to solve? You can't do this in JavaScript, really, since the runtime provides no control over what happens to string primitives when they're garbage collected. – Pointy May 18 '15 at 19:20
  • @Pointy: I take "clearing the password from memory is not usually done or not possible in a reliable way" as an answer, if this is what you are trying to say. This is the first larger JavaScript-based client application I am working on and of course I am interested in the best practice approach here. – Dr. Jan-Philip Gehrcke May 18 '15 at 20:22
  • The thing is that a web application must rely on a set of security-related behaviors to be properly implemented by client browsers. Things like protecting against cross-site requests and correctly implementing cookie security are similar things that your code just has to trust. Each window (well, each family of windows) gets an isolated JavaScript runtime environment. Furthermore, since there's no low-level raw memory allocation, there's really no way to scan free memory (short of exploiting a browser bug). – Pointy May 18 '15 at 21:23
  • Why are you so focused on a memory attack? Pretty much every web app that requires a standard login form runs the risk of being exposed to a memory attack. I'm not sure that it is something that you need to focus on. – Neil Smithline May 18 '15 at 21:40
  • Related: [What happens to form / JavaScript data when browser window is closed?](http://stackoverflow.com/a/27886541/413180) – SilverlightFox May 19 '15 at 06:51
  • @NeilSmithline: Sure there are much more important security constraints, and I think I am aware of them ;-), so I do not focus on this particular type of attack. This is just one of many questions that came up while working on a larger JS application for the first time. An Internet search did not really reveal how others treat the situation, so I was interested in collecting input on that topic. And your and Pointy's input has been helpful already, thanks. – Dr. Jan-Philip Gehrcke May 19 '15 at 09:58
  • See also [Is there a way to reliably delete/wipe a variable in JavaScript?](http://stackoverflow.com/questions/23266676/is-there-a-way-to-reliably-delete-wipe-a-variable-i-e-key-password-in-javascr) – Sjoerd May 10 '17 at 06:51
  • I think I disagree with previous comments. There are known attacks that leverage the fact that a password is not properly erased from memory such as cold boot attacks or memory scans. Web security require a class of objects that can erase their content from memory. – Mister Ticot Jan 08 '19 at 20:21

3 Answers3

9

As nothing in the various web browser related scenarios makes commitments about the contents of browser memory, you can never be sure that you are clearing memory.

Consider the simple JS code:

x=1234;
x=5678;

Even in such a simple snippet you have no guarantee that you've actually removed 1234 from memory. All you know is that when you reference x its value will be 5678. You don't know if 5678 overwrote 1234 or was written to a new memory location.

Similarly, once the user has entered their password in response to a form containing:

<input type="password" name="p">

You have no guarantee that you can ever erase the memory holding their password; even if you run the form again.

The only way around these limitations is to write a fat client that is run as a desktop app or browser plugin.

Note that none of the above is meant to state that browsers are sloppy with secrets in their memory. They generally try to prevent memory examination vulnerabilities. It's just that you have no insight into what they do and how you can leverage it. Even if you did, it would be specific to each browser version.

So, unless you feel that you need to protect the password more than, for example, your bank, get use to the fact that you must put your users' passwords into the (hopefully) trustworthy hands of the browser.

Neil Smithline
  • 1,526
  • 9
  • 21
6

Use binary/char typed arrays. Fill array with zeroes when you need to annihilate data in memory.

garkin
  • 458
  • 5
  • 10
1

If this is a real risk for your app, your only real choice is to create a page for login that is separate from the application.

You can use a standard login form to submit the password, the response will force the browser to fetch a new page, and all existing memory with a password is ignored.

Jonathan
  • 5,736
  • 2
  • 24
  • 22
  • 1
    The question is about clearing the password from memory. You have no control over how memory is managed in the browser. What you suggest, at best, frees the memory. It certainly doesn't clear it. A memory scan or a process dump can still contain the password in clear-text. – Neil Smithline May 18 '15 at 21:38
  • True. The risk I spoke to is a bug in the client side application that could read javascript variable holding the password after the password was submitted. ie, alert(pwVar); By forcing a separate execution environment for the app vs the password form, you eliminate the chance the variable slips through. – Jonathan May 20 '15 at 18:28