I am working with several organizations. They have formed a coalition and have agreed to share apps they have created. The group is trying to implement a set of Android applications that will be used by first responders on shared devices during a high visibility event. The applications are all 3rd party, by various vendors, and since the group does not have time to implement an SSO solution, they are using an app called Keeper to allow the users to store their credentials in a database. This is not an ideal solution, but it’s a time crunch. The biggest issue that they are looking at right now is that, although they can set Keeper to log out of the Keeper app itself after a set amount of time, the applications that the user was logged into will all remain logged in unless the user manually logs out. This means that at shift change, unless the first user manually logs out of all of their apps, the second user will have access to all of their applications.
One of the ideas that they had was to create an external Android script that would allow the user to logout of all applications with a single click. But it seems like this would require access to session ID’s and other information from all of the 3rd party applications. If that were possible, it seems like it would be a scarily large security flaw.
Can anyone shine some light on this for me?
Related
I am creating an iOS and Android App and I want to create a screen where the player can start with a guest account or can connect his account with our own accountsystem.
But my question is: Can I detect a user after the app was uninstalled and installed again?
I know that there is something like the vendor. But this will change.
I know that other apps also can do this.
With the user's permission- have them log into an account. Or provide you with their google of facebook account info. So far as hardware ids, those are discouraged and actively being removed to prevent people from the API to prevent this.
Also remember- that unless the user logs in with an account, you don't really know whether it is the same person. You could know its the same phone, but you don't know if he gave it to his kid sister to play on. Or sold it when he got a new one, and now you've given the new owner access to someone else's account. Also, if you rely on hardware ids you won't know its me when I buy a new phone and download it on that.
So yeah- either have him log in with a username and password, or use a 3rd party signon mechanism like Google or Facebook.
For iOS, there is a recommended approach to do that: by using the DeviceCheck framework. The idea here is that it allows you to persist 2 bits of data across app installations on each device. You can set the first bit to 1 if the user has already installed the app or 0 otherwise. And use the second bit, for example, to check if the user has signed in or not.
The official documentation is pretty good, please check it out.
The downside of this approach is that you will also have to do some work on the backend side.
UPDATE:
If you specifically want to detect the account, there is no reliable approach. One of the options is to use identifierForVendor or generate some kind of device fingerprint (for example, by combining the device model, timezone, locale, etc.), but of course, this will not work every time.
Uniquely identifying a device is a security leak, and all platforms are putting serious restrictions on unique persistent identifiers because of privacy concerns.
I'd like to share data "globally" between applications (not activities). The problem is, I have several applications that need to have only on user session: say you log in to one app and if you open another app it won't ask for you to log in again, but will "remember" your id, and that you are logged in.
I have found this solution using the SQLite.
The apps, I'm talking about won't be on Google Play so theoretically this approach could work, I am however worried that someone could just write a rogue app and set the id in the AndroidManifest.xml and have access to all other apps without authentication (I'm writing enterprise apps, so this could be a serious security breach).
Another possible approach would be to have a separate app only for logging in and storing sessions, that all other apps access with intents... this however seems very messy for several reasons (life-cycle, etc.)
Any thoughts / alternatives?
Any tips on how to implement a trialware model for Android apps? I plan to release my app as a free app that expires after 30 days unless the user buys the license via an in-app purchase.
I can use the Android Market API to tell if they bought the license, so my main question is how to prevent the user from un-installing and re-installing my app every 30 days? Can I save something to their phone in a permanent and reliable way that will remain on the phone even if they uninstall? I know nothing will stop a determined hacker, I just want to stop the average user.
I am also open to different approaches to going trialware on Android.
Thanks in advance,
Barry
Have you read the documentation on Application Licensing? Specifically, have a look at Implementing a Policy
I also have found this resource very helpful in determining the best way to get a unique ID for any one device. Android - Identifying App Installations -- They discuss pros/cons to the different approaches -- Straight from the developer's mouths!
I would avoid leaving unwanted remains of the application on their phone.
Instead, you can take some unique identifier of the device, and send it to your server, if this ID was not registered before, send it activation code, if it was, don't send it.
Store this activation code in some shared preferences etc. and when the application starts, check if the activation code is there and if it is valid.
They don't even have to uninstall, just clean app data. You can save something to an obscure location on the SD card, but that's also fairly easy to circumvent, even easier if they read this forum :) Your best bet is to have the app call home to your server and check if licensed periodically. That of course comes with it's own problems: do you allow it to run if network connection is never available, etc.
I would like to use in-app billing in my android application (instead of creation 2 versions of application - free and pro). If user paid, then additional options in Preferences should be available.
My application synchronizes data with website (not my).
Each time synchronization happens, I would like to check if user paid or not.
How should I do it?
I think the easiest means for you would be to use Managed purchase. More on it is at http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type
The "manage by user account" purchase
type is useful if you are selling
items such as game levels or
application features. These items are
not transient and usually need to be
restored whenever a user reinstalls
your application, wipes the data on
their device, or installs your
application on a new device.
Update: website and API updated refer this now https://developer.android.com/google/play/billing/api.html
There are to many ways to do that, i will try and give you some of the most used
what about user accounts? can your application support users? if it does, its practically solved with 1 user per 1 account. just add a flag to your DB for each user. this is the most secure way, its very easy to know if someone is stealing from you thats why all MMO's (like WOW) use this type of check. you can easily know if theres more then one user on an account as well
the downside is that it requires more processing and some support is case someone's account gets stolen or other user support of that kind.
you can save a sort of key inside your application. and some other key on the server. if the key matches (either 1 to 1 or after some manipulation) then you have yourself a paid user, other you dont.when someone buys the application then change the key on the device.
just do what you dont want to do and have 2 applications for free and paid it will probably be less work then the other 2 list above.
there are many ways of doing what you want. but i'll tell you this:
most applications use method 2 but on the opposite direction, meaning serial key.
i dont think your gonna create an mmo so theres no need for option 1 unless you really dont want anyone hacking your application (which i assume no matter what you do it will be hacked in todays world. i'll advice you to trust those who pay and accept those who dont)
method 3 is just easy in my opinion especialy when you want to just remove menu options, but it also creates duplicate repositories for code.
good luck. what ever you decide is good, make a theft protection, if someone wants to steal it, they will, dont fight it (even PS3 got hacked in the end)
I'm creating an Android application for a fantasy league as part of a college project. It's a paid application, and requires each download to be associated with only one team.
I'm confused as to how best go about it. If a user goes to settings and clears the data from there, all files, settings and databases would be deleted rendering a locally stored indicator for "The app has already run before and hence user is registered" as pointless.
Another option that had come to my mind was to store the IMEI no on a remote database (with SHA1 encryption to protect the data) but the problem with this is that, if a user loses or changes his phone, his further participation would be impossible. Additionally, users understandably don't like to share IMEI numbers and it's acceptable.
The best solution in my mind was to restrict usage of the app to the Google account that was used to download the application. With this, even a change of handsets would allow further participation of the user. However, I've not been able to find a way to obtain the Android Market account (only require E-mail) which resulted in the download.
So, my question is, how do I best go about with the problem that I face? Is there a way to get the Android Market username? Or is there a worthy alternative?
The server-side option is what you want, you can get a unique id from each phone and use that as your identifier.