I started to writing my first Android App.
I've tried to create a simple system which will allow user to get info, if he will authenticate with fingerprint.
I wrote fingerprint auth system to get confirmation if user is registered in the phone, but my question is: Is there any option to get "hash" of the fingerprint and store it for ex. in database to check if user should have access to the app?
I mean:
Database key: 123123123123ASDASDASDASD
Fingerprint key: 123123123123ASDASDASDASD
User has access to the app.
If read fingerprint key not equals stored in database, user doesn't have access to the app.
Is this even possile? - is there any other option to create system like above?
By DB, are you talking a local DB or a remote one? If remote- that's a horrible and insecure idea. You should never use a fingerprint to authorize someone on a remote device- all I need to do is get a copy of someone's fingerprint, pretend its mine, and send it as the hash to gain access. Fingerprint capture and authentication needs to be done on the same device.
If local its still a bad idea. All the functionality you need is built into the fingerprint and account APIs. Use them. Don't store people's private biodata in unsecured storage (a db is unsecured storage).
Related
I have been trying to implement a login screen that takes a username and password.
Once the user has logged in once I want him to have the ability to login with the device owner's fingerprint.
I was wondering what would be the correct way of handling this login.
I could encrypt the username and password and save those to shared preferences and once a fingerprint that is authorized is entered I will insert the decrypted username and password (I am looking for a solution like ios keychain).
Should I go with this approach or there is a programmatic way to get the names and passwords.
I have already used a library which verifies if the fingerprint is recognized you can see it here:
https://proandroiddev.com/5-steps-to-implement-biometric-authentication-in-android-dbeb825aeee8
https://github.com/anitaa1990/Biometric-Auth-Sample
There are many way to create an authentication app. Using SharedPreference is also a way to create such apps. But, one limit of SharedPreference is it can only storage data in limited
memory space and data is offline (data is stored in local machine and can be lost if you uninstall app). There are many online library for online authentication, if you are learning or developing a small app then I recommend you to use Firebase Authentication. It can help you create user account, authenticate user by mail, phone number,...and also link to real time database, storage on cloud and many other services (if you need). Please refer following link to get more information about firebase!
https://firebase.google.com/docs/?authuser=0
Is there an equivalent to iOS's Keychain on Android?
My understanding of the Preferences API is that it is not encrypted. For my application it doesn't matter whether these credentials are persisted across devices (i.e. a different use-case to iPhone-like Keychain in Android?)
I also looked at the KeyStore API but it seems to leave the actual storage of user credentials up to the application developer.
Short answer, there isn't one. But you can expect the filesystem to be secure.
Each app operates under a different user, and the filesystem used to store app data is secured by normal UNIX user permissions. So each app's file access is sandboxed by default. The filesystem also may be encrypted.
This page from the developer's site explains it better: http://developer.android.com/guide/topics/security/security.html
Actually there is:
By integrating Smart Lock for Passwords into your Android app, you can
automatically sign users in to your app using the credentials they
have saved. Users can save both username-password credentials and
federated identity provider credentials.
Integrate Smart Lock for Passwords into your app by using the
Credentials API to retrieve saved credentials on sign-in. Use
successfully retrieved credentials to sign the user in, or use the
Credentials API to rapidly on-board new users by partially completing
your app's sign in or sign up form. Prompt users after sign-in or
sign-up to store their credentials for future automatic
authentication.
https://developers.google.com/identity/smartlock-passwords/android/
Expanding upon #DJPlayer's answer:
Some relevant articles. The third includes a github app that demonstrates using the keystore provider to generate keys and then encrypt strings.
Android Keystore System
Where is the best place to store a password in your Android app?
How to use the Android Keystore to store passwords and other sensitive information
Also see Android Storage Options for ways to store the encrypted password - my recommendation is Shared Preferences.
Note that according to the second article with root access and a bit of knowledge of how your app uses the keystore (which might be obtainable from decompiling your apk), it's possible to hijack the private key and use it to decrypt encrypted material (ex: the persisted password)
http://developer.android.com/reference/android/security/KeyChain.html
Keychain for OS 4.0
I am trying to understanding how the authentication of fb happens on mobile devices(ios/android)?
only for the first time when i installed the fb app, i entered the username/pwd. Thats it. from next time onwards, it will auto authenticate itself.
1) Does the fb mobile app stores the username/pwd on the device in any file?
2) will it use oauth or similar token mechanism? if so, where does the token stored on the device.
I guess, my question is, in which memory/path/filename it is stored, so that it is secured and cannot be accessed by other apps/root users.
Thanks much
That's a good question.
It's dangerous to store a user's password in a standard local directory on a device, for the obvious reason that if the phone is compromised a hacker may have access to a password that is likely shared between accounts (do you have a different password for every service you use?).
However, storing a username to the device's default storage is not-so-problematic, and that is generally the method of choice. For iOS this would be NSUserDefaults.
Now, in the case of passwords and tokens (which are certainly necessary and FB would not cut corners on having token-based auth), both being secure contents that ought to be protected, they are generally stored in some sort of encrypted keychain. In the case of iOS, 256-bit encryption by virtue of Keychain Services.
Therefore, when you build an application with auto-login you retrieve the password and token from the keychain on load. However, if the device were to be lost and end up in the wrong hands all of this data would be encrypted and inaccessible.
Of course, let's not pretend this method is fool-proof: http://arstechnica.com/security/2015/06/serious-os-x-and-ios-flaws-let-hackers-steal-keychain-1password-contents/.
EDIT: Although my background is iOS, I am aware that Android uses Keystore as their alternative.
https://developer.android.com/training/articles/keystore.html
I've been reading documentation that Android and IOS's fingerprint scanning API stores the user's encrypted fingerprint locally. Is it possible to build an application that captures the user's fingerprint, encrypt it like a password and store it in the cloud?
If this isn't possible, are there any suggested workarounds people have explored in the past?
Thanks.
No, you can't get this info out of the device. All you're able to do is validate whether the fingerprint provided by the user matches one that's enrolled in the device. It's basically binary. The finger is recognized or not.
Typically what you want to do is store some kind of generated token in Keychain or other secure storage; after the user locally authenticates with their fingerprint, you use that stored token to authenticate the user with your server.
I'm looking for something like the Keychain on the iPhone, but for Android development. Something that gives me the capability to save small key-value pairs that are persistent and unchanged even if the user reinstalls the application.
Is there something like that? Can I use the standard preferences that way?
I would like to achieve a behavior similar to the way it works with games on a PC - writing the save files to another folder so that after deletion and reinstallation the save files are not lost.
Edit:
The bounty ran out without somebody mentioning the accountManager. I just stumbled over it. Would that be a method to achieve the behaviour described by me?
You you use storage on the SD card like Michael Cramer stated ( Let the user know you are storing data :-) ). The data on the SD card is not deleted when the app is removed.
You could on the other hand use a server which stores all the details which can be downloaded as and when required and instead of using a user name use the IMEI of the phone which is unique. That way even if the user reinstalls the OS he will still be able to refetch the settings.
for getting the IMEI you may refer : How to get the device's IMEI/ESN programmatically in android?
You have the real thing here:
By integrating Smart Lock for Passwords into your Android app, you can
automatically sign users in to your app using the credentials they
have saved. Users can save both username-password credentials and
federated identity provider credentials.
Integrate Smart Lock for Passwords into your app by using the
Credentials API to retrieve saved credentials on sign-in. Use
successfully retrieved credentials to sign the user in, or use the
Credentials API to rapidly on-board new users by partially completing
your app's sign in or sign up form. Prompt users after sign-in or
sign-up to store their credentials for future automatic
authentication.
https://developers.google.com/identity/smartlock-passwords/android/
Since Android & iPhone-like phones will normally run with a data plan, I would suggest that you save your key-value pairs into a centralized server. When the app goes through the uninstall, followed by an install process, just resync it with your server.
Yes. Preferences are persistant and will survive a normal application upgrade.