The problem:
In one of my Android apps, users should be allowed to make changes to text data on my server (via HTTP request) without being required to login or sign up.
In order to prevent spam and abuse of this function, I would like to identify a single installation of my app so that I can "ban" this installation. Of course, the user who is abusing my service could uninstall the app and download it again or something like that. But this is truly an obstacle and makes abusing the app more difficult.
So I have to find a way to identify an Android device or at least a single installation.
As one can read here or here the physical device ID of an Android phone is not a good solution. So what else could I do to achieve this?
My idea:
When the app is started for the first time, create an (almost) unique hash (maybe SHA-512) of the current timestamp and a huge random number. Then save this value on internal storage and always use it to identify this device or installation later (on HTTP requests).
What do you think of that solution? Are there any better approaches?
This is almost what the Android Developers Blog suggest, right? But are they really writing to the internal storage? They don't use openFileOutput() as suggested here.
And, at last, a question that is probably a bit stupid:
How can I use the code shown on the Android Developers Blog? Can I add that public class to my main activity .java file?
Thank you very much in advance! :)
In my current Android project, I use the Bluetooth mac id as the identifier because of what I read about the physical device ID not being reliable. Of course, my app is very specialized and REQUIRES bluetooth AND internet anyway, so this works.
Specifically I have a way of calling my web server from the phone, passing in the Bluetooth mac ID. I can check license status (for trials/expirations), where you might check against a ban method to see if that id is banned.
Since my application requires bluetooth, this worked perfectly for me since [mostly] all bluetooth mac id's should be unique.
Just an idea.
Related
I have an app that has some unknown devices listed in the analytics portal I use.
I was wondering if Android and iOS have a method that I can call which tells me if the app has been downloaded and opened using an emulator?
I've thought of accessing the device's IMEI, but this is only for mobile phones and doesn't cover tablets. Any help would be greatly appreciated.
You can try filtering out the Connecting device's by their device's model number, name and id.
For that you first need your app to parse the data from the phone, and then send this data to your server while authentication.
The server checks the robots list and then authenticates the exceptions (genuine users).
NB: Nowadays emulators are updated, they are capable of spoofing a Device Name, Model and ID. So it's a hectic job to detect spoofer's.
Just a Mere Concept out of Thoughts, Might possibly work!
There are couple of methods out there. Android includes a built in method,but some of them can be maneuvered.
Android includes some system properties that keep such information. they can be accessed using the getprop utility and there are ways to get the problematically.
More specifically, the "ro.build.characteristics" will contain the word "emulator" when running on emulator.
Long story short: There are couple of libraries that are capable of doing this and are consider reliable.
Here is a good example:
https://github.com/framgia/android-emulator-detector
For iOS see this answer
As a side note. if you are concerned about having a safe environment to run your application, take a look at SafetyNet
I'm trying to understand how applications are storing data without the use of a login system. Example, an android app starts you with 500 coins and you use some of them. You have not logged in at all and you delete the 'app data' in settings and uninstall and reinstall. The app still knows you only have 450 coins left for example. The app requires internet connection so I'm assuming they are storing the info on their server. If so, how are they uniquely identifying your device? In my reading so far it seems there is no full-proof way to uniquely identify a device every time.
I'm asking because I'm going to be working on an app where I don't want to require a login but I also don't want the player to simply reinstall and get to start over. So, my question is how does everyone handle this situation to work for both iOS and android?
Google offers Firebase, which is used for notifications, but makes use of a unique identifier for an application instance on a device (both on iOS and Android), they could be using this.
There are some more providers that offer a similar service (for example OneSignal).
Reference: https://firebase.google.com/
I'm rather new to Android developing (a few months), and I'm developing Android application, that must have some security mechanism, that require licensing per device not per account.
I thinking about the scenario:
client have a multiple similar Android devices (for example tablet, the same model)
client buys first license (application gets the license data and store it in the device)
client create snapshot of first device and use it to make software duplication with other devices (licenses allow to run without internet authorization when user have full commercial license), even after all updates (done in first device)
And here's my question: is it possible to detect (or prevent) by application that kind of duplication? Even with required internet connection in every run (or uuid generated by application instead of getting hardware id), duplicated devices still will be recognized as the same model...
Or maybe I'm wrong, and that kind of duplication isn't possible?
There are several more or less unique IDs that can be used to identify Android device. See this example - you may need to use all of them.
On a rooted device with custom build an attacker can obviously fake any ID.
i need to know how can i secure my app to make a close beta?
i want to send my app to some people so that they can test it. but i dont want them to share the .apk with other people and just use it some days. so i need to implement some kind of trial/beta mode.
i need something, that the app e.g. only runs 7 days or so. how to do this?
There are a few ways to ensure security:
Get a server, and have a server side authentication based on a unique device ID, like an IMEI or MAC address. Any device which does not belong to your testers will not be listed on your server, and you can stop the app from running.
If possible, have each person come to you and install the apk yourself, instead of mailing it to them
Create a trial system. Store the date on which the person first accessed your app from the device, and stop letting him use it n days later. If you store this on a server along with the unique ID, it'll be safer, as if it is stored in the shared preferences or something, the user could get around it by clearing the data or uninstalling and reinstalling the app.
Obfuscate your code using a tool like ProGuard. This will add an extra layer of security incase someone decompiles your app
Note that these are only a few suggestions, and none of them are 100% secure. AFAIK, there is no way to ensure 100% security, short having having the devices locked in a lead room, and letting in the testers one at a time. And there is a way to get around that too, I bet.
Use hockeyapp, there's nothing easier to distribute your app to a closed group of people.
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.