I'm required to develop a web application that will function offline for long periods. In order for this to be viable I cannot avoid saving sensitive data (personal data but not the kind of data you would only store hashed) in local storage.

I accept that this is not recommended practice, but given little choice I'm doing the following to secure the data:

• encyrypting everything going into local storage using the stanford javascript crypto library and AES-256
• the user password is the encryption key and is not stored on the device
• serving all content (when online) from a single trusted server over ssl
• validating all data going to and from local storage on the server using owasp antisamy project
• in the network section of the appcache, not using *, and instead listing only the URIs required for connection with the trusted server
• in general trying to apply the guidelines suggested in the OWASP XSS cheat sheet

I appreciate that the devil is often in the detail, and know there is a lot of scepticism about local storage and javascript-based security in general. Can anyone comment on whether there are:

• fundamental flaws in the above approach?
• any possible solutions for such flaws?
• any better way to secure local storage when an html 5 application must function offline for long periods?

Thanks for any help.

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, you can use WebCrypto/node or 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.