As with many other founders and their start-ups, I'm low on cash and aiming to launch without funding. The app will be dealing with users health data so setting up a server with the correct encryption may be costly. I am also only familiar with JSON, SwiftUI, Swift5 and API programming so setting up a server is outside my scope of expertise.
Therefore, I aim to launch the app with all user data stored locally in SwiftUI CoreData, as to avoid these issues. With enough users i.e. traction, I will then begin to seek funding, at which point I would hope to set up an encrypted server and transfer user data there.
I am worried that if I launch with local storage, I will not be able to transfer each individual users data to an external server, without them having to reenter all of their information.
I was just wondering whether this was possible or not? And if you could provide details that would be very helpful.
I need add multi-user capability to my single-page mobile app developed with Ionic 1, PouchDB and CouchDB. After reading many docs I am getting confused on what would be the best choice.
About my app:
it should be able to work offline, and then sync with the server when online (this why I am using PouchDB and CouchDB, working great so far)
it should let the user create an account with a username and password, which would then be stored within the app so that he does not have to log in again whenever he launches the app. This account will make sure his data are then synced on the server in a secure place so that other users cannot access it.
currently there is no need to have shared information between users
Based on what I have read I am considering the following:
on the server, have one database per user, storing his own data
on the server, have a master database, storing all the data of all users, plus the design docs. This makes it easy to change the design docs in a single place, and have them replicated on each user database (and then within the PouchDB database in the app). The synchronization of data, between the master and the user DBs, is done through a filter, so that only the docs belonging to one user (through some userId field) are replicated to this user's database only
use another module/plugin (SuperLogin? nolanlawson/pouchdb-authentication?) to manage the users from the app (user creation, login, logout, password reset, email notification for password lost, ...)
My questions:
do you think this architecture is appropriate, or do you have something better to recommend?
which software would you recommend for the users management? SuperLogin looks great but needs to run on a separate HTTP server, making the architecture more complex. Does it automatically create a new database for each new user (I don't think so)? Nolanlawson/pouchdb-authentication is client-only, but does it fit well with Ionic 1? Isn't there a LOT of things to develop around it, that come out of the box with SuperLogin? Do you have any other module in mind?
Many thanks in advance for your help!
This is an appropriate approach. The local PouchDBs will provide the data on the client side even if a client went offline. And the combination with a central CouchDB server is a great to keep data synchronized between server and clients.
You want to store the users credentials, so you will have to save this data somehow on your client side, which could be done in a separate PouchDB.
If you keep all your user data in a local PouchDB database and have one CouchDB database per user on the server, you can even omit the filter you mentioned, because the synchronization will only happen between this two user databases.
I recommend SuperLogin. Yes, you have to install NodeJS and some extra libraries (namely morgan, express, http, body-parser and cors), and you will have to open your server to at least one new port to provide this service. But SuperLogin is really powerful to manage user accounts and user databases on a CouchDB server.
For example, if a user registers, you just make a call to SuperLogin via http://server_address:port/auth/register, query the user name, password etc. and SuperLogin not only adds this new user to the user database, it also creates automatically a new database only for this user. Each user can have multiple databases (private or shared) and SuperLogin manages the access rights to all these databases. Moreover, SuperLogin can also send confirmation emails or resend forgotten passwords (an access token, respectively).
Sure, you will have to configure a lot (but, hey, at least you have all these options), and maybe you even have to write some additional API for functionality not covered by SuperLogin. But in general, SuperLogin saves a lot of pain regarding the development of a custom user management.
But if you are unsure about the server configuration, maybe a service such as Couchbase, Firebase etc. is a better solution. These services have also some user management capabilities, and you have to bother less with server security.
I would like to create a web application using PostgreSQL as a database. I want to have the database encrypted, so that even an attacker that has root access to the database server can't decrypt the data (or at least he would have to mess around with temporary in-memory data which is hard). I don't care about the schema, only about the content of the tables.
I also don't want to store the decryption key somewhere on the application server (neither in a config file, nor hardcoded).
Instead, my idea was to encrypt the whole database (or just tables and rows?) using a key that is provided by the user over the web application and that decrypts at runtime.
Is this scenario possible with PostgreSQL and which options do I have implement this?
Side note: It's a .NET based application (ASP.NET MVC3) and I'm using the Npsql driver.
Use pgcrypto for encryption. But, a superuser can control the log files and tell the database to log everything, every query. And that will include the queries including your passwords.
You might want to use SELinux and SEPostgreSQL.
I develop an app for iPhone / iPod Touch which has to have access to a MySQL database. I wrote a PHP API which I can call from the iPhone app.
In the database I store sensitive data which I want to encrypt. I think I will use AES_ENCRYPT. My problem is where to store the key.
It'd be great of you have any idea where to store the key to encrypt / decrypt so that it can not be seen by any other persons, e.g. hackers.
In general:
Don't keep your key in a part of the server that the web server has direct access to. For example, if your site is in /var/www/home, don't put your key in there. Put it someplace outside the web server's part of the tree.
Make sure that the permissions on the folder containing your key are correctly set. Your PHP app needs to have READ access only, NOT write or execute on that folder (and the key file).
Make sure the server itself has a good password (long, lots of random numbers, letters, and symbols).
Make sure the server is protected by a properly configured firewall, and is kept up to date with the most recent security patches.
As for trying to keep the key and the data separate -- this is a perennial problem for which there is no very good solution. The simple fact of the matter is that your application has to have access to the key. Either that means forcing everyone who's going to use the app to memorize the key -- which is likely to lead to sticky notes on monitors in plain view -- or else it has to live somewhere that the app can find it, either on the same server or another.
Is there a way to password protect the SQL Lite db core data uses for it's persistent store? I want to make the DB available via iTunes but I want to be password protected so only I can open it.
CoreData doesnt have any built in password protection so you are going to have to roll your own encryption or obfuscation mechanism.
Alternatives could be obscure mechanisms (press the invisible button three times?) to send the file by email for returning the data-store to you rather than exposing the Documents folder in iTunes.
I guess the question is there a genuine need for password protection (i.e personal/medical records) or is this just the usual Corporate paranoia. If its the latter I wouldn't put too much effort in. IMHO.