Are ios local database in apps secured? How to secure them? - ios

in 2017 I would like to make an ios App for iphones/ipads in which I will have a database.
The database is the result of 7 years of research. This database is highly important to us. If it gets stolen, it could destroy our business.
Our idea is a medical app.
Users put their symptoms and it queries the database that gives the disease.
A developer told me it was not possible to protect the database. So its offer was simple : the symptoms are asked locally, then it generates a code that is sent to a server (internet). The server reads the code and process the query and sends back its result. The security is done on the server and not on the ios App. I dont like that solution as it is not local.
Another developer told me it was possible. The database is encrypted and decrypted in the RAM. It is highly secured. At least as secured as a server.
I dont know what to think, but I really would like to have your lights.
I would like the database to be highly secured and the app to work in local (no internet).
Thanks for your help
PS: I forgot to add that users never write on the database. They are just using it...

In my openion
If the data is extremely sensitive then it should never be stored offline on the device because all devices are crackable.
The keychain is one option for storing data securely. However it's encryption is based on the pin code of the device. User's are not forced to set a pin, so in some situations the data may not even be encrypted. In addition the users pin code may be easily hacked.
A better solution is to use something like SQLCipher which is a fully encrypted SQLite database. The encryption key can be enforced by the application and separate from the user's pin code.
Other security best practices are:
Only communicate with remote servers over SSL/HTTPS.
If possible implement certificate pinning in the application to prevent man-in-the-middle attacks on public WiFi.
Clear sensitive data out of memory by overwriting it.
Ensure all validation of data being submitted is also run on the server side.

Related

Swift - app that requires communication between phones on different networks

I'm just starting iOS app development with Swift (and in general) and I'm looking to get some information on popular practices when creating apps that require communication over arbitrary networks (i.e. not necessarily on the same network). I tried searching this on google but the answers weren't entirely what I was looking for; hopefully somebody can point be in the right direction. I wouldn't mind paying for a service, but unfortunately I don't know the first thing about backends and don't want to end up overpaying for services that I don't need. For example, I found an API called Parse, but I think it has far too many features that wouldn't benefit my app. Here's the main premise of the app:
There are two versions of the app - one for Admins and one for Employees
The Admins have the ability to post notes to a central list of notes for the employees to see
The Employees can access this list and scroll through it to pick which one they want to open. After a certain number of time, the notes expire and are removed from the list automatically
It's as simple as that. There likely won't be too many notes getting sent at once, so a large database isn't needed. My questions are as follows:
Do I need a database to store the notes, or can I handle it in some other way?
How is communication generally handled? The only things I've come across are ways to communicate when you're on the same WiFi or Bluetooth, but I haven't seen anything outside of that. How does an app like GroupMe communicate to users?
This is more of a general question, but how can you tell if you need a backend or not? I'm still kinda confused on the interaction between the frontend and backend.
Any help for any of the questions is greatly appreciated. I feel as though I don't even know where to start with a project like this.
EDIT: To clarify, I'm just looking for a place to start, not code or any implementation.
It's as simple as that. There likely won't be too many notes getting sent at once, so a large database isn't needed. My questions are as follows:
Do I need a database to store the notes, or can I handle it in some other way?
Yes you need some kind of database. That could be something complex like MySQL or something simple like writing a txt file for each note to the disk, with the filename being the date of the note.
You could use a service like Parse or run your own PHP server and write the software yourself. Parse is cheaper for a small database, running your own PHP server is cheaper for a big one and it gives you more control.
(You don't have to use PHP, but that is the most popular language for these things and it's what I use).
How is communication generally handled? The only things I've come across are ways to communicate when you're on the same WiFi or Bluetooth, but I haven't seen anything outside of that. How does an app like GroupMe communicate to users?
Usually your the phone sends a HTTP POST request to the server with some text in JSON format in the body of the HTTP request.
The server then responds with more text in JSON format in the response.
On the phone you use NSURLSession to handle to do the network communication and NSJSONSerialization to encode/decode the content. On the server, there will be something equivalent available.
Usually there would be a username and password or some other authentication system in the HTTP POST JSON text that tells the server wether or not the user is allowed to do whatever they're trying to do.
All communication between the phone and the server must be encrypted using SSL to protect your users. Do your homework and make sure you get this part right before you deploy your app to the store.
Parse will handle all of that stuff for you, but it's good to at least understand what's going on.
This is more of a general question, but how can you tell if you need a backend or not? I'm still kinda confused on the interaction between the frontend and backend.
You know you need a backend if you want two devices to communicate without being on the same WiFi/Bluetooth network. This is a security feature that cell network carriers (and home broadband ISPs) enforce to prevent malicious activity.
Generally only a commercial internet connection (and commercial router) will allow anonymous incoming network packets to get through to a phone/computer connected via that internet connection. Consumer internet connections only allow traffic coming in from a known source (for example, if you ask Google for some data, the router will temporarily allow Google to send some data to you. But if Google just sends some data without a phone/computer in your home asking for it, then it will be rejected).
You should be able to take what I've written and do a bunch of research.
If you decide to go with writing your own system in PHP, it comes pre-installed with OS X (just has to be enabled) and you can access it by IP address from the phone as long as you're on the same IP address. That should get you started for testing/development purposes at least.
The only part you won't have is SSL. Starting in iOS 9 (it's almost here!) you will need to disable NSURLSession's built in check for SSL or else it won't let you connect to the test server.

Prevent attacker from decompiling iOS app and getting database access

According to this post, it's possible to decompile an iOS application.
How can I prevent an attacker from gaining access to my AWS DynamoDB database? Just having the access keys out in the open like shown on the Amazon developer guide doesn't seem like it would be very safe.
I would think that I could use keychain to store the keys, but I feel like there would be an easy way to get past this for a motivated attacker, given they have the app's assembly source code.
Currently, I connect using Amazon Cognito. All I have to use to connect are the identity ID and the role name. I don't see anything stopping an attacker from simply getting those values and connecting to the database.
For example, what stops an attacker from decompiling the Facebook iOS app code and deleting all of the users?
How can I prevent attackers from decompiling my iOS application and getting access to the database access keys, or at least prevent them from doing any major damage, such as deleting users?
Based on my admittedly limited experience, I'd say that a really motivated attacker will always be able to retrieve the credentials you use to access your database regardless of what you do to your executable. I would, however, question why you application needs to have direct access to your database in the first place.
The usual way to safeguard your serverside data is to use a web service to access it. App contacts web service with request, service contacts db, gets data, sends it back. Since the web service and the db are both hosted on your server and only the web service needs direct access to your db, there is no need to store db access info in your app. Problem solved.
It's impossible. In order for your program to do something, it must contain the instructions that allow the computer to follow to do that thing, which means anyone else can also follow those instructions to learn how to do the exact same thing.
You can use SQLCipher and use your auth's userToken and/or userId as cipher keys.

Best practices for using pgcrypto PGP encryption with Heroku and Rails

Are there any security best practices for using Rails and Heroku Postgres with pgcrypto's public key PGP.
The naive and direct way seems to be to store the private key and password using Heroku's ENV variables. However this seems like it doesn't add much security since both values are now easily accessed by anyone with access to the environment.
The goal of this would be to encrypt any privacy concerned information such as SIN numbers appropriately.
Scenario:
Let's presume you have some fields that, for some generic regulatory privacy requirement, are required or recommended to be stored encrypted, such as government IDs (SIN numbers for example). What is an appropriate or even common process for encrypting this information using pgcrypto.
If someone has an alternative suggestion for a scenario I'd be glad to include that as well.
This question doesn't have an answer until you define your threat model, but your question suggests that you want to store information in a way that even people with access to the server environment can't read it, in which case there are really only these options:
Don't store the data at all. Depending on what you need the data for you may be able to avoid storing it on your own servers for any reason. For instance, you can ask a user to enter their credit card number and immediately forward it to the credit card processor without saving it (which means you will need to ask them for the number again next time, unless the credit card processor hangs on to it for you.) Some payment processing schemes even send the payment data directly to the processor so that your website doesn't have to touch that data at all. Depending on your requirements this may or may not suit your needs.
Store the data only as a hash, like a password. This is useful if you don't actually need the data, but only need to verify that someone using your site has the data. This is universally the solution for passwords and other "secrets" but is useless for other data.
Store the data with public/private encryption, and don't keep the private key on the server at all. This could work if, for instance, the server has the public key in its environment, with which it saves data to the table, but an administrator has to download the encrypted data and decrypt it locally in order to use it. Again, this has severe limitations so you can only use it if your requirements of what to do with the data are compatible.
Store the data with client-side symmetric encryption, encrypted and decrypted only with a client key. This is how e.g. LastPass works. It means that you, the server admin, can not do anything with the data except return it to the user that submitted it. Once again, this only works if your requirements are very narrow.
If your requirements for what you do with the data are not compatible with any of the above, then you have no recourse. You could encrypt the data with symmetric encryption and keep the key in the server environment as a guard against backups or access to the database, but not the application, falling into the wrong hands, but that does not match the threat model of an attacker with access to the operating environment.
There is no one-size-fits-all "best practice" here because the tradeoffs involved in handling a threat model where the attacker has access to the environment are so great that only applications with very specific, limited requirements can guard against it at all. If the server can read the data, then so can an attacker.
Heroku Env
You get some benefit in storing the key in the Heroku env and encrypting in the database because then an attacker can't get the information from the DB either by direct break in or by SQL injection.
You are still vulnerable to anyone who can break into your app server, your Heroku account or any Heroku or Amazon staff that can obtain access to the server.
Separate Secure Server
If you have a large team and or subcontractors that can access your Heroku account you could have a separate server on a separate account or even separate more secure hosting that is reponsible for saving and loading the secrets with only a few highly trusted people having access to it. It could be kept small and simple and only accept requests from your app servers to minimise the attack surface. The server could be designed to limit the rate at which it provided the confidential data from the database to prevent a complete dump being taken rapidly even in the event that your main App server is broken into. It could access the same DB or a different on and perform the encryption/decryption on every load/save request from the app server before passing the result back.
Doing this will add latency and complexity but that is a trade off you can consider against the security gains. To get the secret information in bulk an attacker would have to either break into/have access to the app server and extract the secret data slowly from the secure server without triggering your intrusion detection systems or obtain direct access to your secure server in some way (which should be harder than the main server as there are less accounts to target for social engineering, password guessing and the direct attack surface area should be smaller.).

How to sync app data across multiple i-devices?

I am new to iOS app development and am interested in developing an app that needs to utilize existing technologies to sync app specific data across multiple i-devices (iPhone, iPad, Touch, etc.). As an example, the app can be installed on multiple devices. On one device, the user will initially create an account. Then in subsequent logins, the user may create a task list, and each task item may possibly include a captured photo image. On the user's second i-device, as he logs in, he would be able to see and access the list and images (locally). Can someone explain to me what technologies I can leverage on to implement such an app?
Specifically:
How do I set up and manage the user accounts? Do I Need a dedicated server and sql database set up for my entire user base? And what programming/scripting languages do I need to learn?
How about the mechanism of pushing and pulling app data from one device to another? Do I need some kind of cloud technologies (SaaS?) to handle the storage and transferring of the data?
Any specific open source or commercial products I can leverage on?
Thanks in advance.
Kenny
I personally have not have had a situation like this, but here is what I would recommend.
You will need to have a server set up with database software.
You will need to write an api for yourself based on HTTP POST (REST) or maybe you could write a SOAP service.
I would HIGHLY recommend purchasing an SSL cert. for your server that way you can send the username and password in your request and it will be encrypted automatically.
For the api, you have a whole selection of languages and databases at your disposal. I am personally biased towards asp net with an MSSQL server.
with your api you will need to write methods to authenticate the user, and then save and send your data.
In your app you will simply send web requests to the server (ASIHttpRequest maybe?) and you can receive JSON responses back, which you can then deserialize into workable objects and vice versa.
if you do use asp net, you can use the newtonsoft JSON library to convert your objects for sending and convert received objects.
I dont remember the name, but there also is a JSON library for obj-c that is usable on iPhone.
Use a SQL server and host a database of logins and passwords.
Then, from each device, create a connection to the server, and download the login information for the account.
Also, not to be rude but: Google it.

Securely storing data, how do apps do it?

I'm doing some research on a new project we want to work on, but before we actually take on the project I have some concerns.
This project involves storing a lot of (text) data somewhere on a server, you can think about it like Instagram (but without photos).
So you can follow people, view profiles, list of activity ...
The question is, how do these apps send all this data securely to a server?
And what kind of server do they use? Something like Amazon AWS?
They are sent over https which is built into the NSURLConnection class. You can have a server (I use linux but you can use anything) have a self signed ssl certificate and your App code can give an exception to that particular URL for self signed certificates if you are wanting to save money. It is better practice and more secure to have a signed certificate though.
As far as storing it, most don't actually store it encrypted. It is sent to the server running a web service encrypted and then is stored in the database / file system unencrypted. The reason for this is there is a lot of processing power required to compress things and the extra over head of storing encrypted things as well as making it harder to search and index depending on how you do it.
Amazon AWS would work although I run my own server at home. It's quite easy to set up.

Resources