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:
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?
Best Answer
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.
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.