Options for client-side encryption of local web databases

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:

https://security.stackexchange.com/questions/10529/are-there-actually-any-advantages-to-android-full-disk-encryption

Also…

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.

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Client-side_databases

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?

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.

Sensitive data transfer of TCP network to the server.
Storage of sensitive data on the device
Identification of user on the device
Identification of device to the server
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…

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.
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.
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)
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.
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.

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.

Edited (after comments)

First of all

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.
Deciding to save data to the client application, without a robust synchronization policy, can create problems of data consistency (apart from safety).
Deciding to save data to the client application, can result in a complex system of synchronization increasing database workload (a hell).
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:

The user must log into the system at least once;
After login, we will carry out the synchronization of local data with the server;
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);
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.

Filed under: softwareengineering - @ 09:24

Thẻ: client-side, encryption, mobile, web-applications

Thiết kế website giá rẻ

Danh mục