I am currently building a system for mobile phones, the system requires some sort of a login sequence and at the moment I am just using an MD5 generated API which is connected to the user in the database but this is using sessions and so on and has so far proven to not be as good as I had hoped, so now I am trying to build a new login where the user enters the API once and the system detects some sort of ID from the phone, like the SID or MIN or something like that, I have no idea this is possible or not. So to recap
Is what I have described possible?
What is the most reliable ID that I could fetch from the mobile device?
How would I go about fetching this ID?
Related
I'm, working on a security scenario for an Android Application to prevent sending unwanted/spam or multi-requests by users.
These users are unregistered and as you know one way to detect them is by checking the IP addresses but the problem is that the public IP Addresses will change. Users can turn On/Off the modem (as an example) to get the new public IP Address or can install/uninstall the app to refresh everything and start sending unwanted requests to the server.
I want to make something like a token and store it on the phone that it will send with their request and on the server-side, we can detect which these requests come from which phone/user and handle the security issues.
This token or ID must have these features:
Access to it (deleting) should be impossible or hard for normal people (not for
hackers, I know it's impossible)
If the app has been uninstalled/installed, Android OS doesn't remove
it
Is it possible?
Is there a better solution to handle this?
The Android developer docs have a good article on available user IDs. Getting the second property will be difficult because Android has been pushing for resettable IDs for user privacy. The firebase installation ID (FID) is close, but you don't get #2. You can also use SafetyNet APIs to see if the app is genuine and then build rate limiting in the client or server side.
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 am making a webapp which will coordinate with an iOS and Android application. There will be a two types of accounts. One will be primarily on the website and the other will be primarily on the Android or iOS app. This question may be too broad, but I'm looking for an authentication pattern which will work for this setup and make sure that the right web account is pairing with the right mobile account. Here's what I've got so far and am hoping you can provide some feedback...
When a mobile app is installed, it will reach out to the server with information such as name and phone number to which a UUID will be returned.
If the web account wants to link with a mobile account, the web account must enter the phone number of the mobile app they want to link to. The server then sends a message to the mobile device so that user can confirm the pairing.
Are there drawbacks to basing the account id on a phone number? Is there a better way to do such two factor authentication? Sorry if this is too vague or undirected and thanks for any help!
Phone number is a bad UUID because there is no way to get the phone number. Other than asking the user. Not reliably. Also, some devices allow dual sims (home and work) and thus would have multiple phone numbers.
A better way is to use the android device id. But even that isn't that great- I could write an app that calls your service with whatever id I want. There's a reason RSA keys use a cryptographic token that changes every minute- it requires you not only to know the id, but to know what the id is now. Otherwise you'd just need to have found out the secret id once and you're in for life.
In my app developed by Phonegap, there is requirement below.
1. Only limited devices are able to use our app. Every device needs to get register key from the back-end before using app.
2. When a user want to log in with the specific account in another device and he has gotten a new register key, the key of the previous device will be disabled.
Any help is appreciated.
Following is the scenario:
I have an web application accessible via mobile browser.
I need to detect a mobile device IMEI and sim IMSI whenever an user clicks on link in my app page accessible via web browser. This is to track the same device with same SIM and provide him/her next level of access. User cannot be tracked using loginid as there is no user login kind of option in my page.
The question is how to get unique device id/sim id via mobile browser for a specific mobile device.
For now I am focusing on android based mobile devices. But the target is to make it generic to devices.
Focus of most of the ideas is, what is the kind of access a browser has over the phone and its app?
From a browser link we can open a local app in the following way:
Get Details
here productcateory will uniquely identify a local app and invoke it. But its one way communication. How to get back some response from the point of invocation and populate some hidden form field dynamically.
Via webpage scripts we can store some data locally at client machine and retrieve it later. but the scope is limited and it is no way connected to IMEI or IMSI number.
Is there a way to get a hook to mobile browser app(remember it's like any other mobile application) from the webpage and get the id details via scripts in my page?
Is there any option that html5 provides in this regard? I know there is a localstorage tag in HTML5 and one can store an id in the client location and retrieve it later. But this is limited to the same device and same mobile browser and also this is a different solution to get the imei/imsi number
Let me know if there is any other option without asking user to installing a local app or browser plugin on the device?
~inkriti
For very good reasons it is impossible for the web browser to access the IMEI or IMSI numbers of a mobile phone, without some dastardly hacking that the dev teams hadn't expected.
Also the android browser doesn't support plugins.
Your only option is to create a native app. This answer has some info that will be useful to you: Programmatically obtain the phone number of the Android phone. Its not a perfect solution however.
I would also ask why you want access to the users phone number? If its just to track session just use javascript to generate a unique id and store it in a cookie.
The original issue is probably closed, however for future reference of anyone (like myself) that comes across this question would be something like 2-factor registration with confirmation via text. The closest to getting an IMEI (impossible without native apps) would be to get the user to register and include a text confirmation - the mobile phone number in most cases will be unique, only non-unique when changing devices, and some assumptions can be made from the client-side to guess what device they have, you could even go a step further and ask them to identify the make/os of their device if you were that concerned about unique-ness. However in most use-cases a mobile number confirmation will do the job
The only reliable way is to write an app and have it send a SMS and then track the number on that end; assuming the subscriber has SMS/text service enabled. This won't work on non-phones (tablets).
It is not important, nor is it necessary and it is probably illegal to track the device (IMEI); simply track the subscriber.