0

I am thinking of creating a app that will contain personal user information for a memberships scheme, the basics, name, dob, a user ID and a valid from / expiry date.

I want to reduce the instance of hacking and having the data stolen. So I was thinking that I add the user information in the database, when the user logs in for the first time, the app connects to the data and downloads the users information to their phone and all personal data is removed from the database, the ID is used for the app to display valid from/expiry dates etc.

I am unfamiliar with iOS/Android app development. Can this work, do I store in a separate file and download to a user area in the app package or do I download a database to the phone, and what about when I need to update the app?

Naz
  • 900
  • 2
  • 10
  • 25
  • what makes you believe that data is unsafe in database and safe in phone memory ? – Vivek Mishra May 10 '19 at 09:39
  • @VivekMishra If someone hacks into the database then they could potentially take all the data. If just the necessary data is moved to the phone and then removed from the database, there is essentially no valuable data left in the database work stealing. – Naz May 10 '19 at 09:42
  • database is stored on phone's internal storage, so someone can hack into your database, then they can definitely access the downloaded file too – Vivek Mishra May 10 '19 at 09:44
  • @VivekMishra You misunderstand, my fault, the database in this instance is an online one not part of the phone. So on first login the users data is downloaded from the online one to the phones one, and then removed from the online one. – Naz May 10 '19 at 09:47
  • so according to you requirements, once you have deleted the data, how the user will able to login on other devices say a new phone that he/she purchases ? – Vivek Mishra May 10 '19 at 09:49
  • Because you have deleted that from online database and new phone won't be able to get data from old phone – Vivek Mishra May 10 '19 at 09:50
  • @VivekMishra That's correct, they will need to contact me to reset their login. – Naz May 10 '19 at 09:56
  • Better to keep your data encrypted – Vivek Mishra May 10 '19 at 09:57
  • @VivekMishra I though of encrypting it, but then you have to store the key somewhere online and that makes it vulnerable. I would prefer just not to store the data. – Naz May 10 '19 at 10:15

1 Answers1

1

This is not good system design

In reality if a system is designed properly, with a security focussed mindset and deployed in a properly designed environment, this should not be a concern that warrants causing end users such potential issues.

In fact, user data would be considerably more secure on a properly designed, controlled system than on a user's device; How many people do you know that don't have a passcode on their phone, or have it set as their date of birth? I know a whole bunch of these types of people (and by logical extension, the passcodes to their phones).

You also mentioned that the data will be deleted from the database. How exactly will it end up back in that database in the event of a support ticket? If it's by emailing it back to you, that would be a bigger security risk because plain text email is not secure.

What you should do instead

  1. Build a web service to sit between your app and the database
  2. Pass the login details from the application to the web service and perform authentication/authorisation there. If successful, pass back an access token of some description. Save this access token to the database with an expire-time value.
  3. Have the app call various api endpoints, passing the access token as part of the Authorization header (so it doesn't get cached or end up in the logs of proxies and web servers etc). If the token is valid, fulfil the request and return the requested data back to the app from the web service
  4. On log-out/quit, have the app remove any sensitive information from the device memory if security is such a concern.

Additional Notes

  • As with any such design, you should ensure that all communications are done over a secure channel.
  • Ensure passwords are stored in a secure format and not transmitted or stored in plaintext anywhere. Use a secure channel for passwords in transit, Bcrypt is good for storing passwords or consider implementing Secure Remote Password Protocol.
  • Ensure that direct access to the database is only allowed from your web service and not the wider internet
  • Ensure that your webservice sanitises input, escapes output and is not vulnerable to SQL Injection attacks.

The benefits of this approach are obvious:

  • Your app data remains secure so long as the environment is secured using the correct tools. If you choose the right hosting provider they'll also be able to provide help and support securing your web server and database.

  • In the event of a user changing their device, logging out or whatever else they'll be able to log back in as they see fit. This will meet the already well established expectations of users and reduce potential support calls.

  • If you decide to expand on the features of your app later on, you can add new tables to the database, new endpoints to the webservice and new functionality within the app to consume said endpoints.

  • Many users tend to have a bad habit of reusing passwords; With a properly designed system you're able to audit login attempts, lock users out for a period of time after so many incorrect password attempts, force password expiry or resets and allow for self servicing of password changes to the whims of your more security conscious users.

Will Jones
  • 1,861
  • 13
  • 24
  • I think this is really useful. I will clarify something. The data held by me is basic user data name, dob, picture, nothing you would not find on a users phone anyway. On a single phone it is not valuable, but thousands listed in a corporate database creates a headache for security and GDPR. I am certain that no matter what steps are taken that you mention above, someone will do something and the database security will be weakened, and that no matter what you do that database will be compromised at some point. So I want the least amount of data in the database even at the cost of usability. – Naz May 10 '19 at 10:52
  • 1
    The thing is, your approach will not solve that problem at all. If you're that concerned about those problems it's probably best you have someone else build and host that system for you in a way that'll be more secure. Whilst you should not sacrifice security for usability, you should also not sacrifice usability for what is in essence, paranoia. Social networks, online services, banks, local authorities and private companies all do what I've outlined above and whilst you cannot reduce the risk down to zero, steps can be taken to harden an environment to make it less attractive to attackers. – Will Jones May 10 '19 at 11:01
  • I would not call it paranoia, which is an irrational or delusional fear. As you mention social networks, online services, banks, local authorities, NASA, FB, FBI, CIA do the things you mention and they have all suffered security breaches. I don't see how my approach won't solve the security problem. – Naz May 10 '19 at 11:16