I need to know how to get the phone UID when read by an NFC reader. The reader has to uniquely identify my phone so that it can be used to open a door.
Do you know if this is possible? I've been looking and have not found how.
In the event that it isn't possible, what do you recommend?
The current Android does not support tag emulation, so I must assume you will be using some kind of P2P protocol when talking to your door. If the phone sees the door as a passive unit, thats the same.
A key insight in your plan is that you should encrypt the communication to your door, and that the encryption key is really what matters. Any unique id you come up with can be faked, no matter where it comes from.
I'd put the encryption key somewhere online in a properly stored file. So then you are also covered once you loose your phone or it just breaks.
My approach would be to make a Google App Engine app which lets you sign in using your Android (email) account; i.e. an app which signs the user in using the built-in Android accounts. Put the encryption key there, possibly behind yet another password.
There are different device specific numbers which you may use.
IMEI = International Mobile Equipment Identifyer, a number phones have specific for their hardware
Mobile phone number, this is depending on your mobile subsciption
There is also the ANDROID_ID, which is a unique number for a Android device. However there appears to be a glitch in V2.2
See also these articles:
How to find serial number of Android device?
Android Tablet Serial Number (not IMEI/DEVICE_ID/SERIAL)
Device SERIAL NUMBER
Related
I have a application which have a refer system
I get user imei no. to as a id of the user
but I checked my application I bypass my application using some app cloner have a funtion to set random imei no.
so how to protect my application from this things
Don't use the IMEI. First off- you can't get the IMEI on modern versions of Android. The OS itself will lie to you unless you're a preinstalled carrier app, the device owner app, or require a permission that normal apps cannot be given.
Secondly- not all devices have IMEIs. A tablet without cellular connectivity won't, for example.
Thirdly, its a massive invasion of the user's privacy (and illegal to do in some locations). Here's google's guidance on what to do for unique ids for your app https://developer.android.com/training/articles/user-data-ids Specifically note that you are NOT supposed to use any permanent hardware id as a user id.
Im developping an application with android studio, the application is for attendance using fingerprint and I want be able to register fingerprint of users using a desktop application and the fingerprint will be registered from a physical fingerprint reader, data encrypted from it will be stored in a Mysql database. So I want users to use their android phone with fingerprint sensor to respond the attendance. Actually I dont know if it is possible to compare encrypted fingerprint from android phone and for this coming from the physical fingerprint reader.
What I need is just ideas on encryption or comparison between those two sources of data.
Thank you
From what I can understand is that you are trying to develop an application with two ends.
One for the fingerprint enrollment from a desktop application.
One for matching the fingerprint to a probe fingerprint of an individual from an Android Device.
See what you are trying to achieve is a bit nearly impossible as #Michael clearly stated.
The answer is a bit elaborated. (The boring but detailed stuff)
For the enrollment part, if you are using a physical fingerprint reader, that device will definitely provide you with a fingerprint image along with some ISO templates of the fingerprint whose name shall be kept unique by you and it's name can be stored in the Database. Let's call this ISO as gallery ISO.
For the verification part, there are two approaches.
1:1 fingerprint match(the person first claims to be someone and places his/her fingerprint on a verification device to confirm the claim) and 1:N fingerprint match (the person doesn't tell your verification system who is he/she, but simply places his/her fingerprint on the device and the system searches for a probable fingerprint match)
Android devices store a fingerprint which cannot be accessed by the API, all you can achieve is that either a YES or NO. That the fingerprint is enrolled in the device or not.
You will have to use the same physical scanner connected to an USB OTG to the android device, if the physical scanner provides the SDK to support android device then it's fine else you cannot just have the same ISO template from any other scanner.
However there is a standard template and most of the scanners generate it.
Like ISO-19794-2/FMR
The ISO generated at the verification end shall be called a (PROBE ISO).
Your fingerprint scanner's SDK shall really provide you a function like below:
long score = CompareISOs(byte[] GalleryISO,byte[] ProbeISO);
The "score" gives out a value which tells you how much confidence is the scanner that the two ISO templates are same and SDK must also provide you with a threshold like say 800.
so if score anytime after comparison is greater than 800. You have a match.
This is 1:1 verification.
one-to-n is a way more hectic task and requires much complex SDK like ABIS. That I shall leave as a research topic for you.
I hope my answer helps you to some level. I came along this question and decided to reply because you genuinely asked for some ideas. I hope this helps you to kick start your research on fingerprints.
Kudos!
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.
http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID
This link says that :
When a device has multiple users (available on certain devices running Android 4.2 or higher), each user appears as a completely separate device, so the ANDROID_ID value is unique to each user.
http://developer.android.com/about/versions/android-4.2.html#MultipleUsers
While this link says:
Beware that if your app requests one of the hardware device identifiers (such as the WiFi MAC address, the SERIAL number, or the ANDROID_ID number), they will provide the same value for each user because these identifiers are tied to the hardware and not the user.
Both are from android developer and have got me confused?
Is the ANDROID_ID actually unique or not for multiple users on a single device?
There is an issue opened here.
It appears to be an error in the doc, so ANDROID_ID should be different for multiple users on a single device.
Best thing is to test yourself, if you have a 4.2 tablet, but some others have tested it here for example, and it appears to work well.
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.