I'm looking to install an android app on a set of tablets for internal company use. These tablets will be used in the field and I want the password to expire after 30 days and switch to a pre-determined (but random seeming) password every 30 days. I'd like that password to be unique for every tablet/install of the app. I will be installing the apps myself on each tablet before distribution.
I looked at various OTP schemes but couldn't find one that would work without requiring to connect to a server. To be honest, I've never done anything like this before and was a bit overwhelmed. Most of these tablets will not have access to internet while in the field and I'd like to be able to have users call in to get the next password after 30 days.
So ideally there's a pre-determined sequence of pseudo random numbers for each device, the user is given the password for this month and after 30 days, they have to call in to get the password for the current month for their specific tablet.
Hope this makes sense.
Thanks
Alright, I'll stream a couple of ideas I have about how you would achieve this.
My first thought when reading this was "You can do all of this through interacting with a Server, and frankly it would be easy with that support" until, of course, you noted that this wasn't possible.
I am making these suggestions under a few assumptions:
No one from your company is going to try to exploit the app in any way - like overbuffering or changing the apps language or utf settings etc etc. Also they won't try to look at any of the source files.
You will always get your hands on the devices before the people in your company use them.
Alright then, the handling of the 30-day predicament: The easiest way (though also most error prone way) would be to the get the systems current time (and date) when the user logs in, and set that "day" as counter "30 or "0." This can be done with Time now = new Time();
now.setToNow(); or Calendar c = Calendar.getInstance();. Store this "day" in your own SharedPreferences or just the DefaultSharedPreferences. Every time the app starts check this day with your current day, and calculate how many days it's been. If the current amount of days is 30 or greater, reset the password.
^This was one of the most simple, and also very "error...full?" (Couldn't think of a good word) ways to solve this. Now on to the passwords:
I would recommend using UUID for the passwords. Although the identifiers made aren't "technically" unique, the chances of getting the same password twice are...well so close to zero in your case it's probably not going to happen.
Generate these and store, lets say 1000 different ones into a file onto each device (a simple text file with each password on a different line will work), and save a copy in your own records (Make sure you know which passwords go to which device).
Then when that calendar counter from earlier goes off, set the password for the app as the "next" password in the file, deleting previous one from the file. The company employee calls you with his app Id (Generate an app ID the user can see in each app. So the first person who gets his app has app #1, the second is app#2 etc. so that you know which password file you should be reading from) you can send him the new password.
These are two veeeeeerrrryyy simple ways to handle this, but they might be able to at least get you thinking. Hope I helped a bit.
Related
I have an app where visitors register from their phone numbers (much like WhatsApp or Telegram). I store the number in e164 format.
Once he is connected, the application synchronizes his contacts with the database in order to see which contact is using the application. during synchronization the application retrieves the list of numbers from its phonebook and converts them into E.164 format before sending them to the server. so far everything is working fine.
Here is where the problem arises: recently, a country (the Ivory Coast) has decided to change its phone numbers from 8 digits to 10 digits. What's the best way to handle this?
Treat a phone number as an arbitrary value until you can verify it works. Countries change the structure of their telephone numbers all the time and in unpredictable ways.
What is valid one day may not be valid the next. What rules apply one day may not apply the next. There is absolutely no way of knowing what might happen.
Phone numbers do not really adhere to any standard at all. E.164 only establishes the calling prefix, so that's something that might follow standards, but even those can change arbitrarily as countries get created, or merge.
In other words, this is all political and there is no way of predicting the future.
I'm new to app dev...
I read somewhere in the doc: "...In most cases you want to use SharedPreferences as it is automatically backed up and migrated to new devices..."
On first install my app saves a few settings with SharedPreferences. It works great but if I uninstall the app or install it on another device the preference settings are lost.
How can I have these settings saved online within google somehow to be able to retrieve them if the user changes his phone or similar...
Could someone point me in the right direction ?
I read somewhere in the doc: "...In most cases you want to use SharedPreferences as it is automatically backed up and migrated to new devices..."
Your words "backed up and migrated to new devices" is nowhere written nor its true.
We use SharedPreferences in order to minimise the database operations, its like keeping variables handy.
On first install my app saves a few settings with SharedPreferences. It works great but if I uninstall the app or install it on another device the preference settings are lost.
If you wants to store or remember the device dependent settings, use device id / imei_id and store it on your web server mysql database
Even if user uninstalls app from the device and installs again anytime in future, make a call with async task to server by sending deviceid / imei_id and fetch its settings from mysql database and show it.
How can I have these settings saved online within google somehow to be
able to retrieve them if the user changes his phone or similar...
If user changes device, you can do nothing.
One way is, keep public device_id levels keys on server.
If user changes device and uses that key, then show him a response, this key is assigned to another device, but if you are the same, wait for our support
Call him, confirm he is the same old user with new device and delete his old entry from mysql and assign old key to the new device entry
Or use OTP SMS system to identify already existing customers with unique phone numbers
If OTP authentication code is correct then fetch settings for that user from the server, delete old mysql entry, modify new entry with old key and mobile number
This should be the your direction
Edit : 2 ##
I was hoping an easier solution exist but....
There is no short cuts for developers till the date, and it will be never.
Why, no short cuts / easy ways ?
Any device ( mobile, desktop / laptop / any AI device ) which is operated by a system software, is able to perform the tasks as per it is structured.
Ex : android is java based, obviously you can Make javascript based apps, but it is the extensions to the existing system, Android still has the base of Java virtual machine. ( Dalvic / Malvic like )
So, it is always better to use native java
Yes, Kotlin is best option now a days and better than hybrid approach
Every way has its own advantages, disadvantages
If you are developer, should go with native approach
Now your java code never knows, which version it is running on, so you have to, check android versions programming wise, and decide the flow for above Marshmallow & below marshmallow too, and it is explicitly done by developer by coding.
Ex, once user registers, he never shown please register again screen, it is not the magic, nor google, nor, java, nor android does anything, developer has decided, planned, architectured, designed, coded, tested that.
Even developers needs to take care of exceptions, you need to handle it in order to save your app from crashing.
In short developer is god, who creates his own universe, and everything is pre-planned and verified thats it.
You should use allowBackup = "true" in your manifest file. More details can be found here: AutoBackup
I have a situation where admin has defined both English and Spanish Language at the admin panel. Right now, Whatever the changes he made in admin panel, it is reflecting on the website.
My question that when we have different platforms like Android and iOS, Whatever the changes he made in the Admin panel I want it to reflect in the Android as well. As of now, I have defined both language information in Strings.xml.
I do not think calling server each time for the Labels is a good idea. If i do, it might slow down the app.
In detail, i have a validation message like "Please Enter User Name". And the admin changed the label in the back-end and made it Enter User Name. Each time calling server to get the information is bad idea. I would like to save the information or data for certain periods. say 2 hours or 24 hours.
What is the best way to achieve this?
In my opinion the best solution is to keep it in sqlite. You should check version of strings by calling your API when i.e. application is starting and then update its if necessary.
Unfortunatell queries SQLITE every time when user open new activity/fragment might also slow down your app. In my opinion you should keep your map of string in Application Class or in Object (if you use kotlin) - query your sqlite after checking version of your string or when app is starting if API is unavailable.
I have an Android Mobile App that is really just a calendar & you can click a certain date & a secret code pops up. The user uses that code to enter a competition - they follow the link to the competition HTML page(python script really) & enter their details to enter the competition. There are 100 minor prizes & 3 major prizes. A code can either be a non-winning code or it can win the user a prize(either the minor or major).
So they will be redirected to: http://mycompetition.com/comp.py?code=ABCDEF
Then they enter their age, code & image captcha(avoiding spammers) & click enter competition.
My Problem: I am having difficulty coming up with an algorithm to ensure that people just don't type in the above URL & put a random code value for the CGI 'code' value & accidentally win a prize if they guess a correct code(or they use a bot to keep trying).
Can you come up with any ideas to avoid someone who has not purchased the app just going to the url above & typing in a random code & accidently winning the prize?
My algorithms/ideas:
- Have the code 12 characters long which makes the probability of guessing the code very slim but still possible. I am bad with maths & probability so if I use 26 char & 10 digits as potential chars in the code does that mean the probability of guesing correct 1 out of (36 chars * 12 pass length * 103 prizes)? Does that probability leave only supercomputers(not that I believe anyones going to devote a super computer to my comp :P) able to guess the code?
- Dont associate a prize with a code. Instead just have the android app randomly generate some code that means nothing & when they enter the competition I just give them a random 1/10000 (I dont expect anywhere near 10000 entries into the comp) of winning a prize. To enter the competition you have to enter your age & the code & then enter a captcha to avoid spammers.
- Is there any easier algorithm you know of that avoids users who haven't purchased the app getting a prize?
EDIT:
- What about whenever the App is downloaded I look at their phones(wireless part) MAC address. On 1st run of the app I upload that MAC address to my server that contains a list of MAC addresses of users of my app. When/If they discover the secret code, they clikc enter competition & are redirected to http://mycompetition.com/comp.py?code=RANDOMMEANINGLESSGENERATEDCODE&uniqueID=USERSMACADDRESS. In my script I check that the uniqueID is in my list of users who downloaded my app, if it isn't I dont proceed, if it is they have 1/10000 chance of winning a prize. Can you see any flaws in this algorithm?
Use an HMAC to generate the code based on a secret you share between the Android app and the site. As the text for the HMAC, you can use a random value, which you include in the resulting code, or something unique to the user, such as their email address (meaning that each user can only have one valid code). If the length of the code is important, you can truncate the hash produced by the HMAC, but bear in mind that the shorter you truncate it, the more practical a brute-force attack is.
As long as your users cannot discover the shared secret, this will be secure insofar as an attacker would have to guess at random, or attempt to determine the secret by brute force. Since the code runs on user-owned devices, though, there's no way to prevent them from extracting the code from your app. A user with a rooted phone and a disassembler could do this relatively easily. To combat that, you could obfuscate the code, and release new versions of the app, updating the secret key there and on the site, whenever you suspect it's been compromised.
Ultimately, because the device is in the user's control, there's no way to totally prevent users from generating their own codes, but using an approach such as the one above, you can make it much more difficult for them, and easier for you to recover from it.
This question already has answers here:
Creating an Android trial application that expires after a fixed time period
(13 answers)
Closed 9 years ago.
My android application should work only for 1 month after its release. What to do for that?
Please see this question, it has a good answer.
I will give you my experience with trials. At first I tried just using the date on the phone, but then realized if they uninstall and re-install this can be bypassed. This could be fixed by storing the install date somewhere on the file system (hidden), but what happens if the user wipes data or finds the file?
I also tried to just check the date/time at a server anywhere (maybe your www site?), but this imposes restrictions on your application because they must have internet. Soon I realized the need for better license management, so the last solution was used.
The last solution would be to setup a server. You can use the device's unique ID (whichever you choose - I went with the Bluetooth MAC ID because my application requires bluetooth as well), post to a server to check if the user has a trial, if they don't I issue them one, if they do I check the expiration. Now I have complete control over when trials expire. Since my application is a business app that is used in the field, this is very handy if a potential buyer needs another week.
The only issue with the last solution is that if you plan on publishing to Market, you must use their payment system.
Good luck!
Just to add a bit more code-related as well:
Use SharedPreferences to store the date on first-start up
Get the date at every start up - you can use for exampe Date.currentTimeMillis() - and calculate if 1 month has passed
Check current date and calculate expiration date.
That should be pretty easy, just read the date on the first start-up and store it, then compare the date for every subsequent start-up with the stored date, if its greater that x days, pop-up a message box saying the app has expired.
Or am I missing something ?
/Tony
Use alarm Reciever instead, and broadcast when it gets expired.
http://developer.android.com/reference/android/app/AlarmManager.html,
here is a tutorial TOO.. http://moazzam-khan.com/blog/?p=157
if you are worried about the data on the device(and you should! unless you encrypt it) you can save the data on a server and retrieve it on each start up.
On the other hand if application crackers worries you, dalvik byte code today is easily reversed using dedexter or smali and with apktools and jarsigner you can actually find the place where the protection is change some jumps, fill the rest of the code with nops to keep it aligned and resign it uploading it to some crackers market where they share it. So it wont help you too much.
You can make life hard for them if you obfuscate your code with proguard, but it will slow them down,wont stop them.
If your app is web based, meaning the user will need to obtain server data from you, create a key for the registered users that will be received from the server (you can base it on their private details + IMEI) and verify your requests with it, if you get wrong\no key from the client reject the request.
It's not 100% proof either since requests could be faked and someone could grab someone else's IMEI and key and face all the requests.
welcome to broken software copy protection world :-)