My scenario is as follows:

  • Web application, run from the browser, designed for mobile devices.
  • Uses WebSQL storage which may contain sensitive data.
  • Uses Application Cache to enable offline use where there is no connectivity.
  • Can connect to an API where even more sensitive data can be downloaded. Authentication is handled with BASIC Authentication, and unencrypted data is transferred over the wire, as the application shall access the API in the following environments/scenarios:

    • On a private, secured, local Wi-Fi network.
    • Over the public internet, over a VPN connection.
    • Over the public internet, through a HTTPS connection.

So far, based on my limited knowledge, the security of sensitive data transferred over the wire is covered. However, the data 'at-rest' in the local WebSQL storage, and formatted in the HTML pages of the web application, is not secure.

The current concern is if a mobile device contains sensitive data, and it is lost or stolen, how to minimise the risk of the sensitive data being accessed.

As the application needs to be usable without interaction with the server, any software-based encryption would be contained on the client itself. This means that, presumably, attempting to encrypt the WebSQL database will be pointless as if a skilled intruder can bypass the hardware encryption, they can presumably determine the encryption/decryption logic as well?

The proposed solution for encryption of data at rest, is to use the built-in hardware encryption that is part of iOS and Android devices, requiring users to enter a password at the lock screen. There are related 'remote wipe' features as well that could be used.

Q: How 'secure' is the proposed solution? If the built-in hardware encryption is not enough, what are the best strategies for implementing client-side encryption of WebSQL data without need of interaction with a server?

Is the implementation of a software-based, data encryption/decryption solution, only going to give a marginal security benefit, as the encryption/decryption code can be accessed and reverse engineered? Is it just me, or is the main benefit of that merely marketing purposes, i.e. being able to 'say' that it is encrypted?

Interesting links:



Underlying storage mechanisms may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.


Does this mean the only secure option is to produce a hybrid application? E.g. using Phonegap. Is this a great deal more secure, could it just be reverse engineered to view the JavaScript that encrypts/decrypts in the same way anyway?

  • have you considered to implement two-factor Auth, send REST data encrypted with the 2nd factor and session id?
    – kedoska
    Commented Mar 18, 2014 at 16:43
  • 1
    I think even on lan or VPN connection, you should still always use HTTPS. It will be easier to manage and no risk of screwing up the public internet option.
    – Andy
    Commented Mar 20, 2014 at 0:39
  • 1
    As a guide, NHS guidelines (UK) require sensitive medical data that contains patient identifiers to be encrypted to AES256 across all networks, including inside the N3 medical network. HTTPS alone does not ensure this, you have to make sure that you check the encryption level actually used on the connection and reject lower encryption levels, as HTTPS will drop to AES128 quite happily. Commented Mar 21, 2014 at 8:02
  • 1
    Its also worth pointing out that with medical services, even that someone is using a particular medical service may be clinically sensitive. e.g. Drug, STD, HIV or mental health services often have strong social stigma attached to them, so seeing traffic from a patients home IP address to a medical service IP address would be sensitive as it allows that kind of a link to be infered between a patient and a medical issue. The fact that the data was encrypted to AES256 does not keep this confidential Commented Mar 21, 2014 at 8:05
  • 1
    @AdamMarshall, welcome to the world of writing software for the NHS. In that same document on page 12, for all new system deployments it recommends the minimum key size of AES256 or TwoFish256. If you are introducing a new system, my advice is to enforce AES256, as its fairly trivial to do and it eliminates an area of 'discussion' as you are going through approvals. Commented Mar 21, 2014 at 12:17

3 Answers 3


I have worked in the past on medical applications running on portable devices that need to communicate with a central server, but need to also work when no network connection is present.

The first thing to do is to do a proper security analysis. What are the risks to data, and how are you managing to protect the data against those risks. e.g.

  1. Sensitive data transfer of TCP network to the server.
  2. Storage of sensitive data on the device
  3. Identification of user on the device
  4. Identification of device to the server
  5. access to sensitive data on the device by an identified user.

What is appropriate will vary with the nature of the sensitive data, and the product involved, but to give you a guide, here were the answers for that medical product...

  1. Data over the network was encrypted by AES-256, and where ever possible we used a private APN network which connected to the server data centre via a private leased line.

  2. On the device we stored sensitive medical information encrypted by AES-256 but without any patient identifiers. Encryption key was device specific so data files could not be accessed by copying data to a different device.

  3. Access to the software one the device was controlled by a 3 digit pin number. This was probably the weakest aspect, as patients then typically chose simple pins (e.g. 123 or 147)

  4. Each device identified itself with a client certificate to the server, and then had to supply additional hardware provided identifiers to the server to validate the device matched the servers expectations. Only the server knew the identity of the patient that used that device, and server identification was all about confirming whether the device was authorised to connect to the server, and which device it was.

  5. In our case, having access to past historic measurements was important to the patients, so patients could view their historic measurements if the device had successfully authenticated with the server in the past 24 hours, and its last successful socket connection had resulted in the device being authenticated.

  • Some really good pointers here, thank you. Number 2 is of particular interest - where did you store the data? Was it a web app or a hybrid or a native app? I'm not sure what device specific information I could access from a web application, obviously a Phonegap application would have access to IMEI, etc. Any recommended resources when conducting your security analysis? Commented Mar 17, 2014 at 13:51
  • I doubt you can achieve this as a web application... we solved it as a combination of native app, and central server using a SOAP web service. doing the web services as REST is probably more sensible these days, but you will need to think about the client certificate generation bit carefully Commented Mar 17, 2014 at 15:38

Mobile web app: If this is a web app, running from the browser and not in a native shell such as Phonegap, how do you use it offline? If it's already loaded and doesn't make requests (not to be bothered by connectivity jitter), yes, that's useful, but this also means that you can't start the app without a connection, right? Since you keep a lot of data on the client, a Phonegap app probably will be a better fit.

Security: Although, I don't know how secure the native storage encryption is (I don't believe it's unbreakable in any case, though), I am pretty sure you should stick to the presumption that the security of your local data isn't the app's responsibility - as you already said, people can protect their devices with password on screenlock. Also, will your app ask for a login on every start? I don't think you would want to force the user to sign-in every time he loads it. If my guess is correct, then what's stopping the intruder to simply fire-up the app and just read the data?

Caching sensitive data: Don't.

  • Thanks for the answer. Another reason for just using hardware encryption alone would be that it removes the need for a login on every start, which would be annoying particularly for a web app where there isn't true multitasking. Commented Mar 17, 2014 at 12:01
  • Yep, I think I said that: " Also, will your app ask for a login on every start? ...". :) Commented Mar 17, 2014 at 12:27
  • Yes I was just kinda reiterating it :) Commented Mar 17, 2014 at 12:57

Edited (after comments)

First of all

  1. Save sensitive data on the client is a matter of agreement between the user and the owner of the data. You should get into the details of the software license, and the privacy policy that claims to offer.

  2. Deciding to save data to the client application, without a robust synchronization policy, can create problems of data consistency (apart from safety).

  3. Deciding to save data to the client application, can result in a complex system of synchronization increasing database workload (a hell).

  4. I personally believe that the device should only be used as terminals, not as part of the architecture.

For those reasons, save data locally is not a good option, and +1 to Nikolay for

Caching sensitive data: Don't.

The customer is right, and not listen to reason

Having said that, if the request is mandatory, and there is no way to convince the customer/owner to move towards an on-demand architecture, you must find all the tricks to increase security within the client, protecting the rights, privacy and in general the access and use of data.

A possible workflow

The proposal (which is one of opportunity), consider the following key points:

  1. The user must log into the system at least once;
  2. After login, we will carry out the synchronization of local data with the server;
  3. After synchronization, a new encryption key will be generated (see details below) and used throughout the session (including after you disconnect from the server and network);
  4. All information processed by the customer, even after disconnection, will be saved in the device, using an algorithm that considers the "encryption key currently available";

Two-Factor Auth

The keys to encrypt data during sessions will be generated after the log in process. The 2nd factor is a key element to maximize the safety of a product that can be defined as "unsafe".

This mechanism ensures that if the device is stolen (for example), the data available locally, will be limited to one session, but most important, the remote system will not be accessible using the device.

What about VPN or ...

A product developed specifically to be used within an intranet, where the device does not have ability to connect to other networks, it does not need high security mechanisms, indeed, that kind of products only need to identify the user (you would use identity certificates, LDAP or similar devilry).

If the application must save data locally and can be distributed in any type of device (which has the minimum requirements), the VPN is no longer a security element within the design.

  • Thanks for this. I would appreciate it you could elaborate in your answer a bit more, particularly in terms of the following 2 questions. The workflow includes "Save To Local". Q1: doesn't that contradict "Caching sensitive data: Don't"? If not then what is your suggestion for the "Save To Local" implementation? Q2: The data would also need to be decrypted locally, not just when syncing with the API, is that acceptable? In other words saved and loaded locally, not just created and saved locally then never 'read' out again. Commented Mar 19, 2014 at 8:46
  • Also, Q3: The workflow includes Two Factor Auth, what benefits would be gained from this over just Basic Auth? The application will be used mainly on private, secure networks (on-site) or over a VPN, and where there are connections over a public network these shall require HTTPS. Commented Mar 19, 2014 at 9:11
  • @AdamMarshall hope this can help to understand my point of view.
    – kedoska
    Commented Mar 19, 2014 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.