WriteOn is required to be fully functional while offline in a browser container using the HTML5 localStorage API - and so we cannot avoid saving sensitive data (personal data - but not the kind of data we would only store hashed) in local storage.
Since this is not recommended security practice, here is an outline of a new pattern for story & book storage in localStrorage to Stamplay/Firebase:
user password is the encryption key and is not stored on the device
serve all content (when online) from WO trusted server only over ssl (from WO JS API to WO server)
validate all data going to and from local storage to the server using owasp antisamy
in the network section of the appcache, do not using *, and instead list only the URIs required for connection with the trusted server
apply the guidelines suggested in the OWASP XSS cheat sheet
There are inherent weaknesses, though:
Lack of entropy / random number generation;
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);
Lack of secure-erase;
Lack of timing characteristics.
Each of these weaknesses corresponds with a category of cryptographic compromise. In other words, while we may have "crypto" by name, it will be well below the rigor we aspire to in practice.
These concerns will likely be addressed in the WebCrypto API, but that is not here yet.
To completely understand the exposure of the above weaknesses, the frequency and cost of the vectors a user may face, and our capacity for mitigation or insurance in the event of failure in the user's behalf: Javascript crypto, in spite of its weaknesses, may reduce the user's exposure but only against thieves with limited technical capacity. However, we should presume Javascript crypto has no value against a determined and capable attacker who is targeting that information of the user. 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, we can marginally decrease the user's technical exposure but may increase our financial exposure from disclosure.
As an exploration of this topic, here is a presentation titled "Securing TodoMVC Using the Web Cryptography API":
It uses the Web Cryptography API to store a todo list encrypted in localStorage by password protecting the application and using a password derived key for encryption. If you forget or lose the password, there is no recovery. This is just a sample.
Even this is still susceptible to XSS or malware installed on the user's computer. However, any sensitive data would also be in memory when the data is stored on the WO server and the application is in use. I suggest that offline support may be the compelling use case.
In the end, encrypting localStorage probably only protects the data from attackers that have read only access to the user's system or its backups. It adds a small amount of defense in depth for OWASP Top 10 item A6-Sensitive Data Exposure, and allows us to answer 'Is any of this data stored in clear text long term?' correctly.
Alternative storage approaches
One option is to use localStorage to keep the editor text saved while in the background sync save the content to a local browser based JS DB...which then can handle publishing to a remote cloudant doc in the background via SSL, then wiping the localStorage clean after saving.
WriteOn is required to be fully functional while offline in a browser container using the HTML5 localStorage API - and so we cannot avoid saving sensitive data (personal data - but not the kind of data we would only store hashed) in local storage.
Since this is not recommended security practice, here is an outline of a new pattern for story & book storage in
localStroragetoStamplay/Firebase:appcache, do not using*, and instead list only the URIs required for connection with the trusted serverThere are inherent weaknesses, though:
Each of these weaknesses corresponds with a category of cryptographic compromise. In other words, while we may have "crypto" by name, it will be well below the rigor we aspire to in practice.
These concerns will likely be addressed in the WebCrypto API, but that is not here yet.
To completely understand the exposure of the above weaknesses, the frequency and cost of the vectors a user may face, and our capacity for mitigation or insurance in the event of failure in the user's behalf: Javascript crypto, in spite of its weaknesses, may reduce the user's exposure but only against thieves with limited technical capacity. However, we should presume Javascript crypto has no value against a determined and capable attacker who is targeting that information of the user. 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, we can marginally decrease the user's technical exposure but may increase our financial exposure from disclosure.
As an exploration of this topic, here is a presentation titled "Securing TodoMVC Using the Web Cryptography API":
It uses the Web Cryptography API to store a todo list encrypted in localStorage by password protecting the application and using a password derived key for encryption. If you forget or lose the password, there is no recovery. This is just a sample.
Even this is still susceptible to XSS or malware installed on the user's computer. However, any sensitive data would also be in memory when the data is stored on the WO server and the application is in use. I suggest that offline support may be the compelling use case.
In the end, encrypting localStorage probably only protects the data from attackers that have read only access to the user's system or its backups. It adds a small amount of defense in depth for OWASP Top 10 item A6-Sensitive Data Exposure, and allows us to answer 'Is any of this data stored in clear text long term?' correctly.
Alternative storage approaches
One option is to use localStorage to keep the editor text saved while in the background sync save the content to a local browser based JS DB...which then can handle publishing to a remote cloudant doc in the background via SSL, then wiping the localStorage clean after saving.
Pouch db