I’m planning on allowing my users to sync their data with the cloud so that if they get a new phone or switch phones (ex. iPhone to Android and vice versa) they will be able to reload their data into their phone. Currently all their data is stored on their phones. I plan on encrypting their data in the database so it isn’t easily readable. However I have been reached out to by universities that could find user data useful (I would of course make the data so that they wouldn’t be traced back to the user, and ask for their consent). I’m wondering if there is a secure way to encrypt user data but also make it so that if I need to decrypt it for research purposes in the future I would be able to do this. Are there any best practices to do this?
I would argue that the obvious solution would also be the ideal solution. You have two tasks that could fairly easily be solved separately, so solve them separately. To do exactly what you are asking for, would require experimental cryptography.
Use state-of-the-art password based encryption for the identified user data that the users store for themselves.
Collect the research data separately, with explicit permission from the user. Generate individual random identifiers for each user, send those identifiers to each phone respectively, and compile the research data on the user phone, and submit it from the user phone to a different data store on your servers.
Related
What is the best practice for saving Android app data (like users' data - every user has SQL database with data of all the other users) on the phone in SQL database?
This is a public app (has been published on the Play Store) and I need to decide how to encrypt the data and where to save it on the phone in that way no one will be able to reach it (not the users, nor other apps)
first of all, you should not store the data of every user of your app on every users phone. It will be difficult to maintain data consistency and more.
Secondly, take a look at the security section of the android development guide. The "best way" depends on your exact use case.
Cryptography is a difficult and important topic. DO NOT just look for answers like "Do it with XY" and implement it without understanding the theory.
Maybe not the short, easy answer you were looking for, sorry.^^
Is there a way for a mobile messaging app to hold messages sent and messages received on the app without a 3rd party (e.g. AWS) having to continually store these messages? My purpose is to bring down my costs. I would still pay for data ingestion and data egression, but I'm hoping to not have to hold the costs of storage, but rather that users can store their important messages on their own phones, and delete them when they're ready. I'm imagining this is how the iPhone's Messages app works. In my mind, this is like creating a photos app, combined with a messages app, etc.
Any verification that this is possible or tips/links for such a practice would be very appreciated!
Yes, this is possible. A server located in the cloud can simply transfer data between two simultaneously connected clients, without ever needing to store that data to disk.
A portion of the data will have to be exist in memory of some form (e.g., RAM), at least momentarily. Taken to the extreme, this space requirement could be reduced to a single byte.
Storage is not particularly expensive, even for this use case. Nevertheless, if your architecture doesn't require any storage, then there's no reason to buy any.
I do not have any good links for you. I don't even know if this concept has a name. But you should understand that this is a very basic concept of computer communication/buffering.
If you've noticed that messaging services tend to like to keep your data in the cloud, well, (forgive my cynicism, but) that's probably just so they can mine it at their convenience.
I am creating a REST server that will be holding a decent amount of proprietary information. I want users to be able to access the information in only the intended way, which is through a map built into an iPhone/Android app. I require a verified email registration to access the server. I will be rate limiting the amount of information any identity can receive, however I want to take it a step further and prevent (or at least try to prevent) an identity from pretending to be my app and grabbing the information in plain text.
A successful example of this is Spotify, you can download as much music as you want however it is difficult(impossible?) to get at the files unless you are using one of their clients.
I have seen questions like this saying it is impossible: https://stackoverflow.com/questions/32084631/how-can-you-lock-down-so-only-your-android-client-can-interact-with-your-parse-p
However they do not explain techniques that companies like Spotify use to at least obscure the data. I am also ok with only holding one request at a time on the client and requiring that they are online in order to view the information.
tl;dr: What is a good way to ensure REST communication with a verified client(Android/iOS), and decrypt the information so that only my app can use it?
You could encrypt the information, I dont know much about this, but what I do know that there is a book called java with jax-rs which deals with the authentication you are talking about.
I haven't been able to find exactly what I've been looking for by searching the web. Basically, I am making an app with digital currency that I don't want users to be able to hack and add coins to their account. I was thinking of 2 methods to do this, I want to know your opinions on them and how you would approach them to be as secure as possible. I'm not too sure about them but here they are:
Store the data on the user's device with an encryption. The issue with this is that if the user has root access, they could potentially decrypt it.
Give each phone a UUID and store their "coin" information in a database. Every time they open the app, they are automatically logged in using the UUID. This prevents the need to create passwords and usernames. The issue with this is that someone could decrypt the UUID off someone else's device and use it on their own to steal it. Also this would make the experience potentially slower and would cost more for me to do.
So what is the best solution? Do you know of any other ways? Thanks in advance.
Extra info: I plan on using LibGDX since it is cross platform and may be a good place to start but it may also limit what I can do. I am willing to use native android and eventually do the same on iOS if it allows for a much more secure experience.
You cannot store data locally 100% secure. As soon as your app itself can read/write the local coin count the "attacker" can as well.
The only secure option is to save it on a server. Of course every increase / decrease of the coin count has to happen on the server itself and be checked for validity before saved.
Note: You cannot "decrypt the UUID off someone else's device" as long as the server is secure.
UUIDs (Universally Unique Identifiers) are unique across space and time. They just are, there is nothing to decrypt.
The problem of digital currencies has been solved: Bitcoin, Litecoin and the spin offs. It is not an easy of trivial thing to create. If you are dealing with "coins" that have any real value you really need to get your scheme and security vetted by a digital security domain expert, expect to pay several thousand dollars.
Root access does not protect the encrypted data, the data can only be decrypted with the correct key, generally 128 to 256 bits of random data. The protection problem moves to protecting the key. About the best you can do is create a random key to use and save it in the keychain (iOS, Android keychain has more restrictive usage). But if the device does not have a good passcode (or any or good) there is little to no security. In general protecting data from the valid user is difficult and usually falls under DRM, needs servers and authentication.
LibGDX: the more obscure coding system you use the less help is available, think carefully about that. Also if you have competition the UI is very important. While it is generally said that you only have one chance to impress the user you have multiple opportunities to make them unhappy/angry ex-users. Cross platform systems tend to have poorer UI and more non-standard from the native UI on each platform.
I'm looking for suggestions for ways to share Android app data between phones running the same app. For example, lets say I have an app that stores a database of book reviews. If person A has a book review that person B doesn't have, what are the options for getting that information from person A's phone to person B's phone?
Currently, I'm aware of the following options:
- Upload data from person A's phone to a server, then download data from server to Person B's phone.
- Write code to have the phones sync up using bluetooth
- Write code to send SMS messages
I'm wondering if there are any more options besides these, and if there's actually a best-practice for accomplishing this?
Ideally, I want the users to simply click a button in the app to make the sharing take place, so I don't want to go down the bluetooth route because that requires the user to do a bit of setup (or assumes they already have set things up in the form of bluetooth settings).
Since the data can be of variable length and potentially large, I believe that would rule out text messaging.
As far as the server route goes, from what I understand this seems to be an ok way of doing things, but my problem is that I have no experience with having users potentially sign in to a server and then uploading data. I don't know of the cost concerns (if any), or of potential security concerns (allowing just anyone to upload data, I'm not sure if I would have to take steps to ensure someone couldn't bypass the app and upload malicious data).
So, can you guys give me suggestions and point me in the right direction? Thanks.
I'm wondering if there are any more options besides these
You could try generating a QR code and scanning it on the other phone. Beyond that, I think you have it mostly covered.
and if there's actually a best-practice for accomplishing this?
That is impossible to answer in the abstract.
Keep the database server side and interface with it via a web service
I too am looking for a solution to this very problem. I'll throw it out there that a fourth, or rather extension of your first option, is to use the Cloud to Device Messaging Framework, though it still requires (as best I can tell) having your own server, though I suppose you wouldn't need to store the database server-side longer than it takes to send the message, provided you keep it under 1024b (or whatever the actual size is).
I don't believe there is a convenient way to monitor/send email in the background. If I could have my app monitor email messages looking for a key subject, then parsing the body, I could probably accomplish what I'm looking for using email as the transport.
The problem with maintaining a server, is that you probably would need to build in a subscription fee to your app to cover the costs of maintaining a server, as one time sales may not be able to cover the ongoing expense.