Can Local Storage Ever Be Considered Secure

Can local storage ever be considered secure?

WebCrypto

The concerns with cryptography in client-side (browser) javascript are detailed below. All but one of these concerns does not apply to the WebCrypto API, which is now reasonably well supported.

For an offline app, you must still design and implement a secure keystore.

Aside: If you are using Node.js, use the builtin crypto API.

Native-Javascript Cryptography (pre-WebCrypto)

I presume the primary concern is someone with physical access to the computer reading the localStorage for your site, and you want cryptography to help prevent that access.

If someone has physical access you are also open to attacks other and worse than reading. These include (but are not limited to): keyloggers, offline script modification, local script injection, browser cache poisoning, and DNS redirects. Those attacks only work if the user uses the machine after it has been compromised. Nevertheless, physical access in such a scenario means you have bigger problems.

So keep in mind that the limited scenario where local crypto is valuable would be if the machine is stolen.

There are libraries that do implement the desired functionality, e.g. Stanford Javascript Crypto Library. There are inherent weaknesses, though (as referred to in the link from @ircmaxell's answer):

  1. Lack of entropy / random number generation;
  2. Lack of a secure keystore i.e. the private key must be password-protected if stored locally, or stored on the server (which bars offline access);
  3. Lack of secure-erase;
  4. Lack of timing characteristics.

Each of these weaknesses corresponds with a category of cryptographic compromise. In other words, while you may have "crypto" by name, it will be well below the rigour one aspires to in practice.

All that being said, the actuarial assessment is not as trivial as "Javascript crypto is weak, do not use it". This is not an endorsement, strictly a caveat and it requires you to completely understand the exposure of the above weaknesses, the frequency and cost of the vectors you face, and your capacity for mitigation or insurance in the event of failure: Javascript crypto, in spite of its weaknesses, may reduce your exposure but only against thieves with limited technical capacity. However, you should presume Javascript crypto has no value against a determined and capable attacker who is targeting that information. Some would consider it misleading to call the data "encrypted" when so many weaknesses are known to be inherent to the implementation. In other words, you can marginally decrease your technical exposure but you increase your financial exposure from disclosure. Each situation is different, of course - and the analysis of reducing the technical exposure to financial exposure is non-trivial. Here is an illustrative analogy: Some banks require weak passwords, in spite of the inherent risk, because their exposure to losses from weak passwords is less than the end-user costs of supporting strong passwords.

If you read the last paragraph and thought "Some guy on the Internet named Brian says I can use Javascript crypto", do not use Javascript crypto.

For the use case described in the question it would seem to make more sense for users to encrypt their local partition or home directory and use a strong password. That type of security is generally well tested, widely trusted, and commonly available.

How secure is local storage of browser?

Do not store the password. Do a hash-encryption on the server side and store a cookie (localstorage or whatever) on the browser, better if you serve it over https. Always do the encryption/decryption server side.

You can see a great explanation on how to do it securely and following best practices in this stackoverflow answers:

What is the best way to implement "remember me" for a website?

The definitive guide to form-based website authentication

Wherever it says cookie you can place localstorage instead.

HTML5 localStorage security

Bad idea.

  1. Someone with access to the machine will always be able to read the localStorage, there is nothing much you can do to prevent it. Just type 'localStorage' in firebug console, and you get all the key/value pairs nicely listed.
  2. If you have an XSS vulnerability in your application, anything stored in localStorage is available to an attacker.
  3. You can try and encrypting it, but there is a catch. Encrypting it on the client is possible, but would mean the user has to provide a password and you have to depend on not-so-well-tested javascript implementations of cryptography.
  4. Encrypting on the server side is of course possible, but then the client code cannot read or update it, and so you have reduced localStorage to a glorified cookie.

If it needs to be secure, its best to not send it to the client. What is not in your control can never be secure.

How secure is HTML5 local Storage for a Mobile Device

Take a look at sessionStorage, which works similarly to localStorage but doesn't keep any data once a tab/window/browser is closed.

This would also be more secure than localStorage as no data would be kept once a session has ended. There is more details on security in the W3 Storage spec.

However if you're storing sensitive data I'd recommend cookies as data in sessionStorage and localStorage can be viewed and edited by the user and is potentially open to XSS attacks.

Is it safe to store a JWT in localStorage with ReactJS?

In most of the modern single page applications, we indeed have to store the token somewhere on the client side (most common use case - to keep the user logged in after a page refresh).

There are a total of 2 options available: Web Storage (session storage, local storage) and a client side cookie. Both options are widely used, but this doesn't mean they are very secure.

Tom Abbott summarizes well the JWT sessionStorage and localStorage security:

Web Storage (localStorage/sessionStorage) is accessible through JavaScript on the same domain. This means that any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks. XSS, in a nutshell, is a type of vulnerability where an attacker can inject JavaScript that will run on your page. Basic XSS attacks attempt to inject JavaScript through form inputs, where the attacker puts <script>alert('You are Hacked');</script> into a form to see if it is run by the browser and can be viewed by other users.

To prevent XSS, the common response is to escape and encode all untrusted data. React (mostly) does that for you! Here's a great discussion about how much XSS vulnerability protection is React responsible for.

But that doesn't cover all possible vulnerabilities! Another potential threat is the usage of JavaScript hosted on CDNs or outside infrastructure.

Here's Tom again:

Modern web apps include 3rd party JavaScript libraries for A/B testing, funnel/market analysis, and ads. We use package managers like Bower to import other peoples’ code into our apps.

What if only one of the scripts you use is compromised? Malicious JavaScript can be embedded on the page, and Web Storage is compromised. These types of XSS attacks can get everyone’s Web Storage that visits your site, without their knowledge. This is probably why a bunch of organizations advise not to store anything of value or trust any information in web storage. This includes session identifiers and tokens.

Therefore, my conclusion is that as a storage mechanism, Web Storage does not enforce any secure standards during transfer. Whoever reads Web Storage and uses it must do their due diligence to ensure they always send the JWT over HTTPS and never HTTP.

Which one is more safe local storage or cookies?

The fundamental question is more secure against what?

The primary threat is cross-site scripting (xss). With regard to that, a cookie is definitely more secure, if and only if it is set as httpOnly.

However, if the auth info is in a cookie, cross-site request forgery (csrf) becomes an issue, and you have to implement csrf protection. Not the end of the world, but you need to care about it. If you store the auth token in localstorage and send it as a header, csrf is not an issue.

Also cookies with an expiry (persistent cookies) often get saved to plaintext files on the client, which may or may not be a valid threat in your threat model.

So in short, it depends. Overall, storing the token in an httpOnly, secure cookie is usually considered the most secure, but it has implications as described above. Storing the token in localstorage is acceptable too in most cases. Even more so because if you need to send the token to multiple backends (on different origins), you can't have it in a cookie, because that would only be sent to its own origin.

As always, the devil is in the (implementation) details.



Related Topics



Leave a reply



Submit