Why do we just leave the email as plain text in local storage? Shouldn’t we at least encrypt it?
2 Likes
What do you suppose we would encrypt it with?
If it is encrypted, then the user would have to decrypt it (via the pass-key) every time they wanted to authenticate an app (that requires the email)…
Though the app could also store the encryption key in memory, which might be somewhat more secure; it would be successful in blocking cross-site scripting (XSS) and other localstorage exploits, though it could still be bypassed by someone who has access to your machine/memory – but one hole plugged is better than letting the ship leak however it may.
Hi @MichaelFedora from what I can tell there are several methods for encrypting local browser storage. It could be there were limitations with all existing methods and that is why they are not encrypted. It could be something else. At this point, I am investigating why we are not encrypting this information. Any user that can pull up Dev console can see someone’s email in the store; so seems a reasonable question to ask, why is it plain text?
I think one of the points that I believe you are missing (at least from what I can tell) is that you can’t just arbitrarily “encrypt” storage and call it secure because it is “encrypted.” There is no standard way to simply set LocalStorage to be “encrypted” by the browser. It requires a key, and that key has to be stored somewhere, whether the user’s memory (in the case of a password), or the computer’s memory/script. If it is the former, it becomes super annoying to authenticate with apps (why do I have to enter in my password all the time?). If it is the latter, local access to the machine would be able to take it and decrypt it anyways, but I would argue that an email address would be easier found via other ways if you already had local access…
The Dev Console has access to the LocalStorage because it has access to everything the webapp has access too – from global variables to LocalStorage to cookies. Email is left unencrypted because, in general, only the webapp that sets the localstorage can access it (therefore only the Blockstack browser can access the email in localstorage), and email is used quite a bit in apps, and therefore encrypting and decrypting it many times over seems to be a waste of resources and the end-user’s time.
In addition, when it is sent “over the wire” to apps after authenticating it is in plaintext – and may or may not be to an HTTPS site and thus could be captured by people listening in to your internet connection! Even then, if it was HTTPS, the receiving app itself would have to store the email either in localstorage as well, and we have no way to enforce keeping it “encrypted!”
I guess what I’m trying to say is that encrypting it is a waste of time on the client side. If we were talking about encrypting it to store in the profile.json, then sure, but we’re not.
I hope this makes sense.
@MichaelFedora so, thanks for that information. At this point, I am not trying to dive into potential solutions to the fact that they are not encrypted. I simply want to know why we didn’t encrypt them, because I have to explain that to users. Anyone can see we are sending plain text, so I am anticipating the question and looking for a succinct answer.
While I often get the answer “this is technically hard to do” that’s fine. But it is useful for me to get that answer, and acknowledgement that it was a choice and the reason for the choice from the development team. While I typically don’t use the exact answer, I can use that knowledge in other ways.
1 Like
Good to know the context – explaining to users can be quite difficult I imagine!
After thinking about it some more, I would actually argue it’s impossible to encrypt it properly. If they can get into your localstorage, then odds are they could use a buffer-overflow type of attack and grab the “key” from memory (if it’s derived/computed based on the browser’s fingerprint), or instead they would just look at the source code on Github to get it/compute it itself. So in that sense, it would be impossible to encrypt it without an attacker being able to generate the key themselves!
I think, more or less, it comes down to depending on the security of the browser rather than the application itself. Protecting the LocalStorage from rogue websites and extensions is nigh impossible with a browser full of exploitable vulnerabilities, but Chrome and Firefox are generally safe enough to put moderately sensitive information in, I would argue.