And what, if any, controls do users (or MDM profiles) have to mitigate each?
I'm not an Apple developer, so I'm not particularly familiar how the features, protocols, etc., inter-relate. Examples:
NSHomeDirectory()
Core Data
CloudKit
iCloud key-value, document, or Core Data storage
Keychain
iCloud Keychain
iCloud Backup
I'm particularly concerned about data an app may save that will outlive app (or app group) deletion, and be accessible to apps from that app group that may be (re-)installed later, creating a potential security / privacy vulnerability.
Can someone please describe the relevant features, the kinds of data that can be stored, and the degree of persistence (e.g., persistent across reboot, persistent across a passcode change, persistent across an app deletion, persistent across deletion of all apps in a group, persistent across "Reset Network Settings", persistent across device erase and subsequent restore, etc.)?
Related
Good day fellow code ninjas,
I am attempting to make my Xamarin forms application be device unique in the sense that you are not able to login with your credentials on any device other than the one you initially installed the application on.
I have deduced that I should be using a guid for this purpose. I have searched online but I'm not able to find much of a guide on how exactly to use a guid to recognize a specific device.
Are there perhaps any resources related to this or any examples of code used to accomplish this?
There are a few layers to this question, firstly:
Can I Uniquely Identify A Device? No
You won't be able to get truly uniquely identifying information about the device such as UDID, IMEI. This is enforced by the platforms (iOS & Android) as a way of protecting users sensitive information.
This process is called Fingerprinting. There are 2 cases that the platforms want to avoid: Advertisers tracking users across apps, Malicious use of unique id's to target a user. In older versions of iOS & Android there were more API's to use to uniquely identify a user but they are being phased out as privacy & security have become greater concerns for mobile users.
What Are My Options?
Lets accept that we can never truly uniquely identify a device, there are some tricks we can use.
Secure Storage
You can generate a guid and place it in secure storage on the devices keychain. This keychain value can be persisted even if your app is uninstalled. You could use this approach to check if the app is unique to the user. There are pitfalls with this approach, it's not perfect but it's the approach myself and many other's use.
It is worth mentioning the behaviour across devices is very inconsistent. The iOS keychain can be backed up to iCloud (if encryption is enabled). Android devices can use slightly different standards across API levels & vendors.
iOS - identifierForVendor
iOS will generate a guid when you install an app, you can use this value instead of generating your own. See the documentation here.
The 2 drawbacks here are you'd need to implement this on a platform level and if they user deletes all of your apps, the guid gets deleted and a new one is generated when they reinstall the app:
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. The value can also change when installing test builds using Xcode or when installing an app on a device using ad-hoc distribution. Therefore, if your app stores the value of this property anywhere, you should gracefully handle situations where the identifier changes.
Edit 1:
Add further clarification: Explain fingerprinting & highlight some platform nuances
I have created an ionic4 firestore mobile app. It's a SaaS application it has monthly subscription payments. My problem is how could I sell the app using firestore's offline capabilities? I mean making the app work offline adds value to my product but the users can use it for ever, with just offline caching. How can I stop users from using it after a month? Thank you.
If you wanted the opposite (allowing the user to continue using the app offline, but not online, after their subscription expires), you could do so by modeling this in the server-side security rules of your database.
But security rules are not applied while the client is offline. So there's no way to use security rules to reject users without a subscription.
This means you'll have to find a way to lock them out of your app itself, typically by storing (in the offline cache) until when their subscription is valid, and then refusing to start the app if that date is in the past.
A malicious user might be able to work around this, and access the data without your app. Since you're not paying for any database services at this point, that seems a decent trade-off. But if you don't think so, you can start looking at encrypting the data, which makes it harder for users to access the cache without your app. At this point you're pretty much in an arms race with malicious users though, so I'd seriously consider if the loss in potential revenue is worth the effort.
Is ih possible to set up realm to be conpliant to HIPAA or the corresponding European laws for healthcare applications?
(Full Disclaimer: I work for Realm)
While full HIPAA compliance depends on your infrastructure and architecture as a whole, Realm was designed with those sorts of high security requirements in mind.
If you're referring to just the Realm Local Database, Realm files on disk can be optionally encrypted using AES-256, which is more than enough for protecting confidential medical information.
If you're referring to the Realm Mobile Platform, then in addition to the on-disk encryption, synchronized data is also encrypted when transmitted between devices. This functionality is on by default and cannot be disabled. Correction: This functionality isn't on by default because you need to provide your own certificates, but is highly recommended.
One of the major aspects of HIPAA compliance is that the entity needs to be in complete control of the hardware in where the data is stored (ie, medical data cannot be saved on third party servers). At the time of writing, Realm is a package you deploy to your own servers, so you are always in control of your own data.
I'm building a shiny app where users upload transaction data to get access to an analytics dashboard. Can I assure these people that their data is secure from sniffers/hackers and will be removed from the shiny server when their session expires? How does this actually work in Shiny? (Note that I'll be hosting my app on shinyapps.io)
This is not to do with shiny, but whatever server you're storing the data on, how you're using encryption/hashing, and software/app security methods you've used to protect against specific vulnerabilities.
Having said that, here's the (rather minimal, IMHO) security statement for shinyapps.io:
shinyapps.io is secure-by-design. Each Shiny application runs in its
own protected environment and access is always SSL encrypted. Standard
and Professional plans offer user authentication, preventing anonymous
visitors from being able to access your applications.
I would say that the burden will heavily fall on you to use good encryption and data storage practices.
There are many official and unofficial guidelines you can look to for guidance on data storage. One which big companies, particularlly companies going public, must follow is Sarbanes-Oxley.
From grtcorp.com:
The Sarbanes-Oxley Act (SOX Act) was passed by Congress and signed
into law in 2002 in response to major cases of financial fraud, of
which the rise and collapse of Enron is the best known. The overall
focus of the measure is on financial reporting responsibilities, and
ensuring that financial audits are genuinely independent.
However, SOX also includes provisions that relate to the security and
preservation of financial data. And the standards set out for its
implementation "recognized that senior management can't just certify
controls ON the system, these controls also have to control the way
financial information is generated, accessed, collected, stored,
processed, transmitted, and used through the system."
Senior management is thus held ultimately responsible for financial
data security, including putting in place appropriate controls and
procedures to ensure this data security. The good news is that
powerful tools, including data discovery and Data Masking, are
available to meet these standards.
I would also encourage you to familiarize yourself with OWASP's list of the top 10 major web app vulnerabilities:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
What is the relationship between IBM Cloudant, PouchDB, Hoodie, Meteor?
I was watching https://www.youtube.com/watch?v=MALKo1bSa4Y which mentions those technologies but haven't yet wrapped my head around the relationships, so I would appreciate a neat textual summary.
IBM Cloudant is a database-as-a-service based on Apache CouchDB. It's a JSON document store whose storage mechanism makes it great of having multiple, partially-connected data sets e.g. a copy "in the cloud" and a copy on a mobile device.
PouchDB is an open-source database that can run in a browser or in Node.js that speaks the CouchDB replication protocol. It can be used to store data on the mobile device, optionally replicating data to the cloud (CouchDB or Cloudant) when needed. This practice is often called "Offline First" development - getting your app to store and retrieve data in a local data store to give the user 100% uptime, even when there's no network connection.
Hoodie and Meteor are opinionated application development frameworks. You can use their scaffolding to build your applications. They in turn may use PouchDB for local storage and/or Cloudant or CouchDB as a server-side store.