Biometric Login That a Hooked Callback Can’t Fake

Biometric login is one of the features users like most in banking apps: a glance or a touch instead of a PIN. It is also one of the easiest features to implement in a way that looks secure but is not.

In a security audit of a retail bank’s Android app, biometric authentication was one of the areas we hardened. In this article, we’ll explain the common weakness, how binding biometrics to a CryptoObject closes it, and what it still does not solve.

---

The Common Weakness: Trusting the Callback

Android’s BiometricPrompt reports the result of a check through a callback. The simplest implementation looks like this in logic:

1. Show the biometric prompt.

2. Wait for onAuthenticationSucceeded.

3. Unlock the session.

The problem is step 3. On a compromised device, a hooking tool such as Frida can call the success callback directly. The app has no way to tell a real biometric match from a faked method call.

📌 Key Insight:

A callback says “something reported success”. A cryptographic key that only the system can unlock says “a real biometric check happened”.

---

The Fix: Bind Biometrics to a Key

Instead of trusting the callback, the app ties login to a cryptographic operation:

1. Create a key in the Android Keystore that requires user authentication before every use.

2. Wrap a Cipher or Signature using that key in a CryptoObject and pass it to BiometricPrompt.

3. Only after a real biometric match does the system unlock the key for that operation.

4. Use the unlocked cipher to decrypt a session secret or sign a server challenge. Login proceeds only if that operation succeeds.

If an attacker fakes the callback, the cipher was never unlocked. Decryption or signing fails, and the login fails with it.

---

Design Decisions That Matter

1. Decrypt or Sign Something Real

The CryptoObject must protect something the login actually depends on — a session secret or a signature the server verifies. Calling the cipher on dummy data and ignoring the result brings the weakness straight back.

2. Decide What Happens When Biometrics Change

Keys can be configured to become invalid when a new fingerprint or face is enrolled. That stops a person who adds their own biometric to an unlocked phone. It also means the app needs a clear flow to re-enable biometrics through PIN or password.

3. Keep a Fallback

Biometrics fail: wet fingers, masks, new phones. A fallback to PIN or password is part of the design, and it must be as well protected as the biometric path.

4. Combine It With Other Controls

CryptoObject binding closes one gap. Root and hooking detection, server-side session validation and rate limiting close others.

---

Callback-Only vs CryptoObject-Bound Biometrics

Aspect	Callback Only	CryptoObject-Bound
What proves success	A method call	A key the system unlocks
Faked callback with a hooking tool	Login succeeds	Login fails
Implementation effort	Low	Moderate
Change in user experience	—	None for the user

How Mobian Helps

At Mobian, CryptoObject-bound biometrics was one of the controls in a remediation plan of 124 tasks for a retail bank’s Android app, alongside overlay protection, hooking and emulator detection, and anti-repackaging checks. Each control was verified by an independent QA security pack, not only by the developer who built it.

Conclusion

A biometric login that trusts a callback is only as strong as the device it runs on. Binding the login to a Keystore key that the system unlocks after a real match means a faked callback gets an attacker nothing. The user experience stays the same; the difference shows up only when someone tries to cheat.

Frequently asked questions

What is wrong with checking only the biometric success callback?

If an app unlocks a session as soon as onAuthenticationSucceeded is called, an attacker with a hooking tool such as Frida on a compromised device can call that method directly. The app sees success without any fingerprint or face ever being checked.

What is a CryptoObject in Android biometrics?

A CryptoObject wraps a cryptographic operation, such as a Cipher or Signature, that uses a key from the Android Keystore. When that key is created to require user authentication, the operation only works after a real biometric check by the system. A faked callback gives the attacker a cipher that cannot be used.

Does CryptoObject-bound biometrics protect against every attack?

No. It closes the faked-callback gap, but it should be combined with other controls, such as root and hooking detection, server-side session checks and a fallback to PIN or password. No single control makes an app secure.

What happens when a user enrols a new fingerprint?

Keys can be configured to become invalid when new biometrics are enrolled. This stops someone who adds their own fingerprint to an unlocked phone from using it to log in, but the app then needs a clear re-enrolment flow, usually through PIN or password.

Which OWASP category does this address?

Mainly M3: Insecure Authentication/Authorization in the OWASP Mobile Top 10 (2024). Binding the key to biometrics also supports good practice in M10, Insufficient Cryptography.