No central database

Question

I have a client that is looking to get a website/mobile apps/desktop apps built that deal with very sensitive data (more sensitive than bank/card details). Because of the sensitive nature of the data, they do not want to save it in a central database but they still want their apps to synchronise (let's say I add some data into my mobile app, I then want to be able to go to my desktop app and see the same data).

I cannot think of a nice, reliable way of doing this and I am not sure there is one. Which is why I am here. Does anyone know how I could deal with this data?

One solution I was thinking about was to have a client side database on each app that would somehow sync between apps, I can see this being very unreliable and getting messy though.

Answer 1

Plenty of sensitive information gets stored in databases. In fact, a central database is probably the most secure way to store this data. Large enterprise databases have tons of functionality to do things like encrypt sensitive information, to audit who accesses it, to limit or prevent people including DBAs from viewing the data, etc. You can have professional security experts monitoring the environment and professional DBAs overseeing backups so that you don't lose data. It would almost certainly be much easier to compromise data stored on some random user's mobile device or laptop than to penetrate a well designed security infrastructure and compromise a proper central database.

You could design the system with a central database that stores only encrypted data and store the user's private key on the user's device. That way even if the central database is completely compromised, the data is usable only by the user. Of course, that means that you can't restore the user's data if they lose their key (say the only copy was on their phone and their phone was damaged). And if someone compromises the key and, presumably, their login credentials, they would be able to see the data.

Answer 2

You need to back up a couple steps and, in consultation with your client, work out a threat model. (Yes, that's a link to a 600-page book; yes, I am seriously recommending you read the entire thing.)

A threat model starts by asking questions like

• Why does the app need to store this sensitive data in the first place?
  • Can you avoid storing it at all?
  • Can it be thrown away after a short time?
  • Does it truly need to be accessible to more than one device?
  • If it must be accessible on more than one device, does it need to be stored on more than one device?
• Who are the people who are allowed to see each user's sensitive data?
  • Can this list be made shorter?
• Who are the people who may come in contact with each user's sensitive data while trying to do their jobs, but have no need to know it?
  • Can this list be made shorter?
  • Can the data be rendered inaccessible to them without harming their ability to do their jobs?
  • If it can't be inaccessible, can it at least be made incomprehensible? (This is what encryption does, in the abstract: it renders data incomprehensible.)
• Who are the people who want to see the sensitive data, but are not allowed?
  • What opportunities do they have to get at the data?
  • What do they want to do with the data once they have it?
  • How angry will they be if they don't get what they want?
  • How much money, time, CPU cycles, and human effort are they willing to spend?
  • Do they care if anyone knows they have seen the data?
  • Do they want to access specific users' sensitive data, or will anyone's do?
  • What do they already know?
  • What do they already have access to?

Once you know the answers to these questions you will be in a much better place to figure out what to do.

Keep in mind that there might be more than one answer to each set of questions, especially the ones dealing with the attackers (the people who want the sensitive data but are not allowed to have it). If you can't think of at least half a dozen different archetypal attackers, with different motivations, goals, and resources, you've probably missed something.

Also keep in mind that the attackers who cause you (and/or the client) the most trouble, are the most likely to make a giant splash in the media if their attack succeeds, or who do the largest amount of aggregate damage, probably are not the attackers who can cause the greatest harm to individual users if their attack succeeds. Your client's company rationally cares more about aggregate damage, but the users rationally care more about harm to themselves.

Answer 3

One option to do the synchronization would be to do it peer-to-peer. This will still require a central server, but that server won't handle any of the data.

When a device goes online, a central server gets a notification with the user-id. When a second device of the same user goes online, the server sends both devices the IP addresses of the other. The devices can then exchange data directly. Caveat: one device needs to act as a server, so at least one can not be behind a NAT router.

Don't forget that you will need strong authentication and encryption for both the notification mechanism and for the peer-to-peer exchange.

Answer 4

Make it somebody else's problem.

Store the data locally in each app, then give users the option to enable synchronization using their own account with a third-party service (Dropbox, Google Drive, etc). Also, think about encrypting any data uploaded to the third-party service (there are pros and cons to doing that).

This gives the appearance that users own their own data, since they have to opt-in to data synchronization. It makes the apps useful for people who don't want any sharing to happen. And it makes someone else responsible (technically and, potentially, legally) for the ongoing headaches of keeping any shared data safe.

Answer 5

Your client's concern seems to be about the visibility of this data. the first question to ask your customer is if the data was encrypted, where can it be stored? Then, ask your customer what kinds of access controls they want in place before the data can be decrypted and processed - where can the decryption key be stored? is is a seperate key per user? etc...

If your customer doesn't want the data stored anywhere, do they want the user to enter it my hand each time?