2

I need to store a refresh-token in memory in an Angular (Javascript) application.

The token will be delivered via an Ajax call upon authentication and then needs to be stored in memory until the user logs off or closes the browser.

I now want to know how I can keep this token safely in memory so it cannot be extracted by console access or a malicious browser plugin which has access to the webpage.

I found some other thread on how to use refresh-tokens in angular but I think the implementation is not safe:

AngularJS - http interceptor - resend all request after token refresh

Would it be safe if I replaced the authService with a private object to store the refresh- and access-token?

3
  • What threat are you trying to protect it from? Note that it's on the client already, so you can't hide it from the user. What attack do you have on mind? XSS maybe? Commented Sep 15, 2016 at 18:15
  • yes XSS or malicious browser plugin or...? I'm not a real expert in these matters Commented Sep 15, 2016 at 20:45
  • I thought about this a bit, it's actually a good question. I wonder what other security people think, hope you get an answer. Commented Sep 15, 2016 at 23:20

1 Answer 1

2

I think there are several different threats against which you may want to protect sensitive data stored in memory (like a refresh token in Javascript).

One that comes to mind is your data being written to disk. Consider things like the PC running the browser is out of memory and starts swapping, or your user decides to hibernate. While in some lower-level languages you can stop the OS from writing certain memory pages to disk even when swapping, you have by far less control in Javascript, and hibernation also cannot be prevented (in any language, obviously).

So one thing to note is that your sensitive info may get written to disk in plaintext (unless there is disk encryption of some sort), and you cannot do much about that in Javascript I think. If this is not acceptable, you probably shouldn't be using Javascript.

Another type of attack could be an attacker exploiting browser or operating system vulnerabilities to access your part of the memory. You can't do much about these either, you just have to trust the OS and the browser.

And finally, there are application level attacks, mainly XSS. I think you can actually protect stuff against this to some extent, mostly by storing data in a way that does not expose it to other scripts, like for example in closures. This article sums that up better than I could.

Sign up to request clarification or add additional context in comments.

2 Comments

"While in some lower-level languages you can stop the OS from writing certain memory pages to disk even when swapping" --- can you? Does not the kernel only provide you access to the virtual memory?
Yes, but you can kindly ask the kernel to not swap it to disk, at least on linux with mlock(): man7.org/linux/man-pages/man2/mlock.2.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.