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.
Related
I would like to use some publicly available data from a government website as a source of data in an iOS app. But I am not sure what is the best / most polite / scalable way have a large number of users request data from this website with the least impact on their servers and best reliability for me.
It is 1-50kb of static XML with a fixed URL scheme
It updates with a new XML once a day
New users would need to download past data
It has a Last-Modified header but no caching headers
It does not use compression or a CDN
It's a government website, so if someone even replies to my email I doubt they are going to change how they host it for me...
I'm thinking I could run a script on a server to download this file once a day and re-host for my app however my heart desires. But I don't currently run a server which I could use for this and it seems like a lot just for this. My knowledge of web development is not great, so am I perhaps missing something obvious and I just don't know what search terms I should be using to find the answer.
Can I point a CDN at this static data somehow and use that?
Is there something in CloudKit I could use?
Should I run a script on AWS somehow to do the rehosting without needing a full server?
Should I just not worry about it and access the data directly??
You can use the AWS S3 service (Simple Storage Service).
The flow is somewhat like this:
If the file doesn't exist on S3 yet, or, if the creation date of the file on S3 is yesterday, the iOS app downloads the XML from the gov site and stores it in S3.
If the file exists on S3 and is up to date, download it from S3.
After that, the data can be presented by the app without overloading to the site.
I think the best way for you is to create an intermediary database where you can store your data in a secure manner.
Create a pipeline that does some data transformation and store in you newly created database.
Create an api with pagination and you desired filters
Also make sure you are not violating any data policies in the process.
I hope this helps.
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.
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.
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.).
I need to set up a server so that files can be uploaded from an iOS app. I don't know how best to proceed. I thought about FTP but not sure if there is a better option.
any ideas appreciated
GC
Also I must add that I will be building the iOS app so can use server APIs in my code.
It's not ideal to set up a blind File/FTP server and hardcode the details into your app because all it takes is one person to intercept the login details and they have access to your server where they can upload (and potentially execute) bad things.
A possible idea could be to set up an API frontend on your server in a language of your choice (PHP, Ruby, Python or similar) where you can 'POST' images to the server. With the API frontend, you can also do validation to ensure that only valid images are being uploaded and all nefarious stuff is thrown away. Then, in your iOS app, you can set up code to interact with your API frontend and send the actual images which will then be stored on your server.
This is a fairly conceptual idea rather than an absolute implementation idea. It does require some thinking/reading and more setup/coding on the server side.
Edit: Just to add, if you only want a central location to store/get your images without controlling it on a per user basis then you may want to look into Amazon S3 as a File Server.