My future app as any other apps using firebase phone authentication may come across a situation where a user changed his phone number and/or his entire device, a new installation and a new authentication are taking place.
Given that I am enforcing writes permissions to specific documents for that specific user, how can I model a recovery procedure so that one can access and write their documents even if he changed phone number and device?
Ask the user to also add an email via user.updateEmail() to the account after they create the phone number account. This can be used to help with recovery if they change their phone. You can then trigger the password recovery flow and then on successful recovery, re-link the new phone credential to the account.
Related
i have Searched All over Internet about how to add new Fingerprint using our own app, but i am unable to find anything, i have also searched on stackoverflow about this and i found some Same Questions to but no one has answered about this correctly, So i have decided to ask this question one more time.
I have successfully Completed the Authentication through Fingerprint
but know i want to add multiple fingerprints to my app
I am making an app where new users Registered first they enter there name,address,emailID,Age and Fingerprint. all the data stored in MYSQLI
after that when the new user Successfully registered, when the same person tries to login, the first thing he should do is to scan his finger when the scan successfully all the Details which he mentioned while Registration will shows up
i mean his Name,addess,EmailID,Age
So, This is what i want it is similar to Bio-metric fingerprint reader but i want to do this with Mobile fingerprint scanner can anyone help me??
I have done this
Fingerprint but no success Help me out thank you
Adding a fingerprint under the direction of the app with a mobile device built-in fingerprint reader/framework is NOT POSSIBLE:
From Android Source Site:Security:Authentication:Enrollment:
On first boot of the device after a factory reset, all authenticators are prepared to receive credential enrollments from the user. A user must initially enroll a PIN/pattern/password with Gatekeeper. This initial enrollment creates a randomly generated, 64-bit User SID (user secure identifier) that serves as an identifier for the user and as a binding token for the user's cryptographic material. This User SID is cryptographically bound to the user's password; successful authentications to Gatekeeper result in AuthTokens that contain the User SID for that password.
The key part is:
A user must initially enroll a PIN/pattern/password with Gatekeeper.
That means that the owner/user must enroll a PIN which will be eventually associated with the Fingerprint.
A user who wants to change a credential must present an existing credential. If an existing credential is verified successfully, the User SID associated with the existing credential is transferred to the new credential, enabling the user to keep accessing keys after changing a credential. If a user does not present an existing credential, the new credential is enrolled with a fully random User SID. The user can access the device, but keys created under the old User SID are permanently lost. This is known as an untrusted enroll.
As you continue reading you read:
If a user does not present an existing credential, the new credential is enrolled with a fully random User SID. The user can access the device, but keys created under the old User SID are permanently lost. This is known as an untrusted enroll.
And perhaps you hope that your app can invoke an untrusted enroll
BUT
Under normal circumstances, the Android framework does not allow an untrusted enroll, so most users won't ever see this functionality. However, forcible password resets, either by a device administrator or an attacker, may cause this to occur.
So apps are only allowed to know if a user has Authenticated a preregistered Fingerprint via FingerprintManager or BiometricPrompt
What can I do
You'll have to look into external fingerprint readers to achieve what you want.
Possibly a Custom ROM would be another path to investigate, but would require a number of changes as the expectation is that each Fingerprint be cryptographically associated with PIN as well (see first quoted paragraph above).
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
Scenario
The user get only the first time free credits in the app. After that we want to do fraud prevention. We need to check if the user and/or the device have not installed the application before.
We can accept the risk of a factory reset or rooted devices
What I tried already
Listen to Intent.ACTION_PACKAGE_FIRST_LAUNCH. After reading I understand that this event is only send to the Play store and can't be used in any other app.
Check the application package info for the field "firstInstallTime", this is reset when the user removed the application and do a install.
Android Backup Service, but the user can stop the backup and reset data, so this is at no use.
App licensing looks like a promise solution to detect if the user have already installed the app. But with limitations the following is described: "You can implement licensing controls for a free app, but only if you're using the service to provide APK expansion files." Do we need to make a small APK expension file, just to verify the license?"
make a fingerprint of the mac address, imei, android id and some other stuff. But would this make the scans of Google play violating? I don't use it for advertising, but i'm afraid they think we violate the google play policy.
how you can help me
Can you help me to choose a good direction to solve this issue and maybe give some better methods to do this verification.
Factory reset, second-hand phones and users with multiple devices will be your main problems.
The only way to uniquely identify a user is an authentication through login/password or OpenId account.
Hey there if you are managing user information at the your server than what you can do is take the IMEI number of the device and send it to your server. It will record the information of the user. Now if he/she uninstall and install app again your app will again send IMEI number at server now you can check the IMEI already present or not, If present then user have already installed your application, more over you can manage same thing from the login ID, but that can be faked by the user. More over it will not violate any thing. User can see while installing in the permissions that your app will get the system information.
whenever user installs my android app, i should get their device info and i like to maintain a webservice about the user who installed my app..is this possible?, is it valid to do that..in general does App development companies will have the user info who installed their app?
Generally, developers keep anonymous statistics, or identify individual users using the IMEI number or the wifi/bluetooth MAC address. It is generally a very bad practice to use the user's phone number. Rule of the thumb is that if you want personal contact details like the phone number or email address, you explicitly ask the user the enter them, and take their permission to use then for whatever purposes. You should never take personal information from the user without their consent.
Is it "safe" to install Android Device Administration applications on my personal device?
Can my company read my private data with that application?
My company recently adopted a policy to install an enterprise application on each employee's smartphone. The application should be installed from 3rd party market that is operated by the comapny, and requires Device Administration privilege.
Even though the application does not require 'root' privilege, and Device Administration API is not related to reading data inside the phone, I'm still not sure that my personal data is safe to my company.
FYI, the API includes changing password, wipe out data, disable camera, and so on.
(link)
As you have mentioned yourself Device Administration API does not relate to phone data per se. The permissions given with this permission are as follows:
USES_ENCRYPTED_STORAGE A type of policy that this device admin can use: require encryption of stored data.
USES_POLICY_DISABLE_CAMERA A type of policy that this device admin can use: disables use of all device cameras.
USES_POLICY_EXPIRE_PASSWORD A type of policy that this device admin can use: force the user to change their password after an administrator-defined time limit.
USES_POLICY_FORCE_LOCK A type of policy that this device admin can use: able to force the device to lock vialockNow() or limit the maximum lock timeout for the device via setMaximumTimeToLock(ComponentName, long).
USES_POLICY_LIMIT_PASSWORD A type of policy that this device admin can use: limit the passwords that the user can select, via setPasswordQuality(ComponentName, int) and setPasswordMinimumLength(ComponentName, int).
USES_POLICY_RESET_PASSWORD A type of policy that this device admin can use: able to reset the user's password via resetPassword(String, int).
USES_POLICY_WATCH_LOGIN A type of policy that this device admin can use: able to watch login attempts from the user, via ACTION_PASSWORD_FAILED, ACTION_PASSWORD_SUCCEEDED, and getCurrentFailedPasswordAttempts().
USES_POLICY_WIPE_DATA - A type of policy that this device admin can use: able to factory reset the device, erasing all of the user's data, via wipeData(int).
The one's which would probably relate explicitly to "privacy" would probably be the ability to monitor, how many failed password attempts has been made, when correct password has been entered and minimum safe password. Other than that it does not make it any more privacy worrying than any other app.
That being said, this in no way makes this app "safe" to install. Some permissions you should be checking would be all the READ_ permissions. http://developer.android.com/reference/android/Manifest.permission.html .
These will give the app direct access to alot of personal information, such as when calls are made who it is made to, what sms's your receive and send. Also READ_EXTERNAL_STORAGE is another big one. It allows apps to read ANY data on external storage which may often contain personal data, i.e. Downloaded images, Screenshots etc, as well as even App data of poorly coded apps (where there are MANY on the market which just leave credentials in clear text on your SDCard).
The RECEIVE_ permissions likewise are able to intercept incoming messages/calls/mms etc.
USE_CREDENTIALS is obviously a privacy risk as well, as it can use tokens that you possess to request data from external API sources (i.e. your Gmail)
Also there are many permissions which don't even need permissions. For example getPackageManager() allows apps to find out a entire list of app the apps you've got downloaded. So they know that you have angry birds or any other naughty apps installed ;)
What I'm trying to say is, this permission itself isn't a massive red light on privacy. But the fact they are installing an App (unless open sourced and MD5 verified) there are many other ways to access "private" information already. Not installing an app will always provide more protection than installing one. Hope that helps.