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?
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.
Use binary/char typed arrays.
Fill array with zeroes when you need to annihilate data in memory.
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays
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.
