I want to increase the level of security of my android device with implementing an auth method that requires a series of fingerprints in a specific order.
For example: pointer finer, middle finger, little finger
To make this work I would need to be able to get a unique identifier for a successfully verified fprint.
So if I would receive the result that the finger was successfully matched with fprintX I could implement such a feature.
Does that work with the biometric auth api today?
Related
If I'm correct, you can store up to 5 finger prints in iOS. I have came across something like weak biometric, meaning the fingerprint may not necessarily be the fingerprint of a primary user, a secondary user can also set one, so we want to restrict the fingerprint indexing to a specific impression.
Is there a way to find the index or know which finger print index was used to set up biometric to login into the application?
localAuthenticationContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reasonString) {
// index of the finger print
}
No. Every registered fingerprint is equally valid.
If a user decides to add the finger print of another user, they give them equal access to everything as long as no passcode is required.
But the majority of users register finger prints of multiple of their own fingers; depending how you grab your phone one finger print is more practical than another. I have left and right index finger and right thumb registered. If one or two of those didn't work with your app, I would be very, very, very annoyed as a user.
I'm integrating TouchID into my app, for security reasons I need to block the user when he is trying to authenticate with newly added fingerprints [Which is added after enabling TouchID authentication in my app].
I can detect the biometry changes using LAContext's evaluatedPolicyDomainState. but this only says either biometric database was modified (fingers or faces were removed or added) or not.
Is there any other way I can find whether user has authenticated using newly added fingerprint
[added after enabling TouchID in my app] or not.
Any thoughts on this? appreciate any help and thanks in advance.
It is not possible to determine whether the biometric authentication took place with a "new" or "old" finger. This is a hardware limitation.
The biometric validation takes place in the Secure Enclave. The Secure Enclave simply returns a yes/no answer to the main processor. The main processor does not have any access to the actual biometric data that was validated.
You can, as you have noted, determine if the biometric database has been updated since you last evaluated the domain state. The best you can do is invalidate all biometric access if you determine that the database has been modified, even if that modification was the removal of a finger.
From the release notes:
Support for reusable Touch ID matches. A match from the previous phone unlock can be used by evaluateAccessControl: and evaluatePolicy:localizedReason:reply:.
To me this means that an event CAN be fired if a different finger is being used.
Abstract Example:
Login with finger 1, and again with finger 1, and again. No event.
If finger 2 is used, event raised. Subsequent usage of finger 2 no event.
I do fully agree that I won't know what finger was used, just that a different one was used. This informaton might give me enough information to act upon.
Use Case
I'm creating an app to assist in domestic violence situations where if a victim is asked to unlock the touch-ID enabled app, and a different finger is used, then the call for help is discreetly erased from the app.
Research
This is not documented on Apple's site outside of release notes, and Diffs however it is present within Xamarin's site. I followed up with the developer forums and don't want to wait for the documentation bug to be acknowledged.
In my scenario, a device is shared between an Adult and a Child, both who are enrolled in TouchID. I need to determine if a different finger is being used to protect sensitive settings.
Question
How do I use LocalisedReasonReply to determine if a different finger was used to unlock a phone? (or am I misunderstanding the new feature)
[Foundation.Export("evaluateAccessControl:operation:localizedReason:reply:")]
public virtual Void EvaluateAccessControl (SecAccessControl accessControl,LAAccessControlOperation operation, String localizedReason, [ObjCRuntime.BlockProxy(typeof(ObjCRuntime.Trampolines/NIDActionArity2V1))]Action`2 reply)
For reference, I pasted the LAContext.h file here
"Support for reusable Touch ID matches..." mean that:-
You can re-use device unlock authentication in your app by specifying time interval in evaluateAccessControl: and evaluatePolicy:localizedReason:reply: methods.
By using LAContext Property "touchIDAuthenticationAllowableReuseDuration", You can reuse Device Unlock authentication in app, these is because at a time of device unlock you already authenticate your self. So it not required to authenticate again.(New Introduce iOS 9)
Note: Time duration must be in seconds. it default value is '0' and you specify duration up to 5 Minutes, beyond 5 minutes does not increase the accepted interval.
As I understand for the moment, the location and time sensitive passes in Passbook only support time and/or location based notifications. So at the correct time and location, the user will get a notification for the pass.
I was wondering if these properties also can be used to change the pass. For example, if you are in some specific store, the coupon provides a 50% reduction instead of a 20% reduction. If it is not possible to do this locally on the iOS device, is it possible to send a request to the server based on location and/or date to achieve the same thing?
Sorry to be the bearer of bad news, but it's not possible to accomplish this.
Firstly, the data within the pass is fixed at any point in time. As you've said, it can be fixed to a list of locations and/or a date.
Secondly, the pass cannot communicate with a server except to request an update in response to a push notification. This means you will never know where a pass is.
The only option way to achieve something like this would be to generate passes using an app that is location aware, but I don't think this is what you're after.
You can send a push update to a Pass at a specific time. This way you can (for example) convert a 10%-off coupon to 20%-off on Fridays (and then switch it back after Friday).
After a user has initially 'Added' your Pass promotion into their Passbook you can update it at any time without requiring the user to 're-approve' your update.
Your server does not know when a Passbook user has triggered a location alert - otherwise you could track their movements via Passbook. Apple does not want their customer's security to be compromised in this way.
However, you could issue a coupon that is normally 20%-off (for most stores, or online) but that the location alert for a specific store said 'Get 50% Off at this store'. When the customer comes in to have their Pass scanned & activated, your server will then know the customer's location and can apply the 50% reduction.
We are building a web based system where there are money involved and we want to avoid fraud implementing a system that is able to identify the IOS device from where the requests are sent.
The reason of this security is because we offer money for execute actions from a mobile and we only want the user to obtain the money once, if we are not able to identify the device the user can execute the action several times.
This unique identifier can use any HTML, JS, server side technique, but not any native IOS call due the application is web based and it runs in a normal Safari instance.
The unique identifier is not needed to be the official UUID.
The system doesn't need to be bullet-proof just a few more difficult to cheat than a normal cookie.
The system should works in separate sessions, like if the user comes back after one week.
Heuristic based systems are welcome, also any combination of LocalStorage with Cookies, ...
The only ways you can identify a unique user/device in a web application is to use cookies and or track the user's IP address.
Of course, the IP address of a device will change as the owner moves around and cookies can be cleared/disabled or will expire after a set time.
Letting web sites access a device unique identifier such as the UDID would be a huge security risk / privacy invasion. If you were to find such a way, I would say that you found a severe security hole in iOS.
If you are only interested in triggering i.e. an email alert when an account is suspected of being stolen, you could use a heuristic based on device type (user agent string) and geo-ip-lookup to detect if the user has suddenly changed device type and continent and ask the user to confirm that this is really the case. I believe this is what e.g. Google and Facebook does.