What is the best way of storing JWT securely in XD?
The only possible ways are using storage APIs
@stevekwak But isn’t it exposed?
It’ll be your “responsibility” to keep it encrypted. This, e.g., could get achieved via libraries like https://github.com/brix/crypto-js.
@plugisto Yes, I am well aware of the encryption methods and how it works, my question is how to “securely” store it, so it is not exposed and available for end users to crawl, something such as HttpOnly cookies.
You may encrypt it and store it in a file, but it is not called “secure” as long as it is exposed.
But in that sense, basically everything (at least on a “client-only” side) is “exposed”, isn’t it (as it has to get stored somewhere on the disk)? If you “have” to save it somewhere, it is, in a sense, exposed (but may be encrypted).
On the other hand: Why should a token be so “hidden” from a user? If it uses some sort of service, the user has to log in and it shouldn’t be the case (by design) that the user may not see his/her own token (I only have to intercept my traffic, use a custom certificate or some other tricks, and can see a token anyway). For tokens not belonging to the users, they shouldn’t be on the user’s machine, but on a hopefully secure server (or, for a user token on the client side, secured by a master password that isn’t stored and has to get entered by a user every session to decrypt the store so that the token’s secure from other users). In every other case, you get security through obscurity, which is (sometimes) ok, but never “uncrackable”, meaning we can’t trust for it to be safe…
There are different levels of security, I understand where your argument is coming from, but unfortunately that does not answer my question, thank you for trying though.
Of course. I wasn’t trying to answer the question with my last comment, though, but more trying to ask for a use-case (that doesn’t fit my “image” about it).
The thing, as far as I see it, is that as long as we assume the plugin source code to be “scrambled enough” to not get reverse engineered, encrypting the information is basically all one needs (as in this case, it is possible to make it as difficult to decrypt as required, this then is no less secure even though it is exposed. Add 1000 files looking similar and it isn’t any more exposed than some storage XD might be able to provide). On the other hand, if we consider the source code to be unsafe (which it basically is without an implementation of something like Can we get some kind of simple integrity check for plugins? And maybe real protection someday?), it doesn’t matter how securely something is stored, as long as a plugin can reach it, I can simply edit the plugin’s
main.js, inject some malicious code and get the secret logged right into the console.
Therefore, my question would be if I’m getting this all wrong (and the use-case is actually completely different and doesn’t have these problems), since in the other case, the above would apply, meaning there basically currently wouldn’t be a way to have a truly secure storage, even if there were such APIs.
@Ali not in the near future