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 av
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.
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.