I'm trying to come up with an app in which I need to access user's emails for some functionality. I'm getting the normal "View and manage emails" permission from the user for the Gmail access.
I'll be storing the email on the user's device. But is it a problem if I store the details on my own web server too? Is that a data policy violation? Has anyone tried that here?
There are also a few apps which actually do something like this - Swingmail, Tripit, Boomerang. I know they store data on the device, but there is no way of knowing if they even store data on their web servers.
Initial research:
I went through the Google API TOS and below are the 3 things that seem to point that we can store data on the web server:
Security: You will use commercially reasonable efforts to protect
user information collected by your API Client, including personally
identifiable information ("PII"), from unauthorized access or use and
will promptly report to your users any unauthorized access or use of
such information to the extent required by applicable law.
Retrieval of content: When a user's non-public content is
obtained through the APIs, you may not expose that content to other
users or to third parties without explicit opt-in consent from that
user.
Prohibitions on Content: Unless expressly permitted by the
content owner or by applicable law, you will not, and will not
permit your end users or others acting on your behalf to, do the
following with content returned from the APIs:
Scrape, build databases, or otherwise create permanent copies of such content, or
keep cached copies longer than permitted by the cache header;
I think we can still store the data for a user provided user grants permmission for that and the devs takes sufficient measures to protect the data obtained from Google APIs.
I'm not sure it's a stackoverflow question, but as I've been thinking about this:
What does Google say about it?
This is in the terms of service, which you have found.
What is your relevant data protection laws say about it
For example in the UK, you need to consider if you are a data controller, and have taken reasonable measures to secure the data, amongst other things.
What is the process you take if you lose the data for instance. There can be financial penalties if you get this wrong.
Are your users informed (this is linked to 2)
Your users need to have agreed to this, in some acceptable form. How do they remove their data, how long is it held, how is it used.
Now, IANAL, but you have to be careful, you will likely be putting things in a Terms & Conditions, which is a basis of a contract, and there be dragons. For example reasonable in UK law can have a host of pitfalls http://www.linklaters.com/Insights/Publication1403Newsletter/PublicationIssue20070605/Pages/PublicationIssueItem2385.aspx
Bottom line? I'd get a lawyer.
Related
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?
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
Build a web service to sit between your app and the database
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.
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
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.
I am about to release an Android app. It requires users to upload photos. While developing it, I used Cloudinary. Can I still use it in release version or do I need to create my own storage? If I can (and to me, feels like I can), what should I add into the privacy policy about it?
Firstly, reviewing the privacy policy provided by Cloudinary, I don't think user's data is at risk. They've mentioned that details to supply into their database wouldn't be shared with anyone else. However, they are legally obligated to fulfill the legal requirements of providing any information to the authorities on demand (that applies to many cloud hosting corporations). However, you must take the following point into consideration:
The content you upload to the Service, whether from your own device or from a cloud-based hosting service, including any data, text, graphic, audio and audio-visual files, may include personally identifiable information. The content that you upload and designate as public, will be accessible to others.
Privacy Policy
Based on further research, when a image is uploaded, Cloudinary generates a random image ID which will result in a random generated URL (I am assuming this will go directly in your database). That URL seems to be accessible by the public but in order to guess that random URL can be a task in itself (so you must be safe). The reason for this being a public domain is partly be able to share the images for another application/platform via providing the URL... more info
Now coming to the next part of the question, using user's information.
Firstly, you'll need to create your own Privacy Policy (Guidance) in which you'll mention all these details. The privacy policy should cover the following points (minimum)
What information do you collect - This includes both information entered by the user i.e. phone number, name, etc or information which is collected automatically i.e. HTTP logs, data usage or anything in the background.
How do you use the information - For example - email might be used for marketing purposes or resetting forgotten passwords.
What information do you share - Are you sharing information with third parties (for marketing, survey or any other purposes) or other users?
Therefore, privacy policy is a major subject which I would recommend you to learn in-depth as it's a
a statement or a legal document (in privacy law) that discloses some or all of the ways a party gathers, uses, discloses, and manages a customer or client's data. It fulfills a legal requirement to protect a customer or client's privacy... read more
Having the user agree to the privacy policy puts you at a safe place as they're agreeing to your terms of how their data will be used. As long as your functionality is acting within the policy.
You need to be aware of the requirements of data processing under the GDPR. In essence you need to inform your customer of what information you are going to process, why you are processing it, where you store it, who you might share it with and how long you will retain it. This needs presenting in a notice at the point the data is captured. You must also inform your data subject of their qualified rights under the GDPR, how to contact your data officer and how to make a formal complaint to the Data Commissioner.
This can be a lot more simple than it sounds but I'd recommend getting an expert to cast an eye over your notices and whatever processes you put in place for the exercising of rights etc. - documentation is key; the ICO will want to see that everything has been considered and documented. Even if you choose to take no action on a point, as long as that decision is documented with justifiable reason, you are broadly compliant.
These guys are good and can certainly help you. A worthwhile investment, as falling foul of GDPR is likely to be expensive!
Steve.
My web server has a REST API. I need to add user authentication to my app, and my thought process behind it is this:
Get the user's username and password from the app form
Encrypt the password and Base64 encode both the username and password
Send the data to the REST API over HTTPS
Web server verifies credentials, returns errors or success
Is this secure? I see a lot of mentions of OAuth2. What is it? What does it do better than my process?
The fact that you used the word "encrypt" for the users password instead of "hash" demonstrates you have fairly limited knowledge about this. This will almost certainly result in you messing up your authentication procedures somewhere along the line and put your users private information at risk.
A really important point about OAuth2 is that it can be used with many existing third party providers (Google, Facebook, Twitter, etc) with minimal effort from you.
You don't need to do anything to store credentials or even authenticate users. The third party takes cares of all of this and simply provides the client with a token (long random string) which is then passed to your server. Your server then talks to the third-party server to make sure the token is valid (and gain any info you need, like the users' name, email address or other information).
You really should consider using it if you can. The big companies put a lot of effort into securing their authentication methods and you gain all of that by making use of it.
A final nice point is that users don't need to create and remember credentials for (yet) another account.
Google has some docs to get you started and includes an OAuth playground to test how it works in practise.
A very basic explanation of OAuth2 is that the user will log into your system, with it encrypting both username and password before sending it, then if it gets authenticated, it will send back a token to the user.
Thereafter, whenever the user tries to contact the web server, it will send this token along with each API call. This is how it makes sure that non-authenticated people can't access your web server.
So basically your current method includes parts of the OAuth2 standard, but not the most important part (The token).
In your situation, how would you stop non-authenticated people from accessing your web server? If the project is small, then the risk of this is not that large.. But for larger companies, this is a real threat that needs to be dealt with.
You should really try to understand the difference between encryption and hashing before providing an authentication portal for your users. There are many different hashing algorithms you can use. I've personally used BCrypt in the past and I have a related SO Question about it as well. You can find implementations of pretty much all the popular algorithms in pretty much all the major high level languages these days.
Obviously if you don't want to do all that you can use an OAuth provider, who will take care of all the hard bits like storing the passwords securely, protecting the database and all the other security aspects for you. There are many reliable OAuth providers, Google, Facebook, Yahoo, etc. etc.
One thing to bear in mind would be the environment in which your app is hosted. OAuth does depend on having a connection available to the OAuth provider's servers every time a user wants to access your app. So, if you are behind a corporate firewall or similar which may block access to websites like Facebook, this might be a big problem.
I personally prefer token based authentication for my API projects. If you're not familiar with token based authentication you can read this SO Question and this link.
The general concept behind a
token-based authentication system is
simple. Allow users to enter their
username and password in order to
obtain a token which allows them to
fetch a specific resource - without
using their username and password.
Once their token has been obtained,
the user can offer the token - which
offers access to a specific resource
for a time period - to the remote
site.
I know very little about security or servers, but am making an Android app that allows users to purchase an in-app subscription. As recommended, I want to use the Google Play Developer API and store the necessary data on my own server. However, I can't think of a way to do this without having a line in my code like
if(userIsSubscribed){
//give access to purchased data
}
A hacker could obviously go in and just flip that to if(true). What should I do instead?
Obfuscate your app code as a minimum. Also do the subscription check on the server, before you send the content. That is one of the reasons they have an Web API.
Basically, anything the user (and potential cracker) has access to (i.e., your app) cannot be trusted. Things they don't have direct access to (i.e., your content server) can be trusted a bit more and it is a good idea to move all sensitive operations and/or data there, where possible.
I'm attempting to implement a system for upgrading/unlocking various features of my app using "managed" purchases with in-app billing, and I'm getting bogged down by the lack of in-depth documentation or examples.
My app's purpose is to retrieve/parse and display data from my own server, and the documentation on http://developer.android.com/guide/market/billing/billing_best_practices.html states:
If you are using a remote server to deliver or manage content, have your application verify the purchase state of the unlocked content whenever a user accesses the content.
My question is, what is the best way to go about this in terms of actual workflow?
As far as I can tell, on successful purchase I would store the purchase information on my server as well as locally in the app. When the app runs, I would send the order ID to my server and the server would check to see if the order is valid (firstly checking that the order exists in my server's database, and secondly checking if I have not manually revoked the order for whatever reason).
If that is verified, the server would send a response to the app that the requested features are "licensed", and the app would provide the unlocked features/content to the user.
The obvious problems I can see with this are:
A rooted user could easily just alter the local app's SQLITE database (or whatever other method I use to store order information) to inject a valid order ID.
If network access is down, or my server is down, I still want the app to be able to run (with cached data) with all the user's purchased features.
Potential ways around the first problem that I can see involve sending some sort of device identifier with the verification request, and monitoring that at my server's end - revoking the order if a large number of devices are accessing the order in a short period of time.
For the second problem, I can't figure out an adequate solution. I initially thought that each time the verification is successful, the time this verification took place would be stored. Then, the app would continue to run with the unlocked features for say, 48 hours after the last successful verification. The issue with that is, how can I securely store this time value? Again, rooted users could simply alter the value and the app would be none-the-wiser.
Has anyone designed a server-based system for managing in-app billing purchases and can offer some suggestions?
Google Licensing provides a way to allow a cached 'You're license is valid' response to stay alive.
Application Licensing
You can also encrypt the data your are storing. If they have paid for it, they get to decrypt it. If no network access available, then implement a similar caching scheme as Application Licensing (currently licensed under the Apache License, Version 2.0).