# Mobile Auth And Biometrics > Use when assessing mobile authentication and biometric (Face ID / fingerprint) implementations — the local-auth mistakes that let an attacker bypass the lock without the biometric. - Skill: `jihedbfr-art/mobile-auth-and-biometrics` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/mobile-auth-and-biometrics` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/mobile-auth-and-biometrics/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/mobile-auth-and-biometrics --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose Mobile apps use biometrics (Face ID, Touch ID, fingerprint) for convenient authentication — but implemented wrong, the biometric is decorative: an attacker with the device bypasses it without ever presenting a face or finger. The common mistake is treating biometric auth as a simple "did it succeed?" boolean that client-side code checks, rather than binding it to a cryptographic operation. This skill covers assessing mobile authentication and biometric implementations for these bypasses. ### When to use it Assessing any app that uses local/biometric authentication, especially for gating sensitive functionality (banking apps, secret stores). Biometric bypass is a common, high-impact mobile finding because the implementation mistakes are subtle and frequent. ### Procedure 1. **Understand the two ways to use biometrics — one secure, one not.** - **Event-based (insecure):** the app calls the biometric API, gets back "success/failure", and *client-side code* decides whether to proceed. This is bypassable — hook the check to return success, and the biometric is skipped entirely (no face/finger needed). The decision is a client-side boolean an attacker controls. - **Cryptographic (secure):** the biometric authentication *unlocks a key* in the secure hardware (Keystore/Keychain/Secure Enclave) that's needed to decrypt data or complete an operation. Here the biometric is bound to a cryptographic result — bypassing the check doesn't produce the key, so it can't be skipped. This is the correct pattern. 2. **Test for the event-based bypass — the key test.** With dynamic instrumentation (Frida/Objection), hook the biometric success callback / the code that checks the result and force it to "success". If this bypasses authentication and grants access, the implementation is event-based and insecure: ``` objection -g explore # biometric bypass helpers ; or Frida-hook the auth callback -> success ``` If the app still can't proceed (because it needed a key the biometric didn't unlock), it's using the cryptographic pattern correctly. 3. **Check what the biometric gates.** Is it protecting genuine secrets (data encrypted with a biometric-bound key) or just a UI gate (a screen the app shows/hides)? A UI gate is bypassable; a cryptographic gate isn't. 4. **Assess the broader auth flow.** Beyond biometrics: is authentication also enforced server-side (a biometric unlocks local access, but the backend must still authenticate the session — the biometric shouldn't replace server auth)? Are tokens/credentials protected (the storage skill)? Is there a fallback (PIN) and is it secure? 5. **Check for local-auth-only trust.** An app that relies solely on local/biometric auth for security-critical access, without server-side enforcement, trusts the client — bypassable. Sensitive operations should be server-authenticated, not gated only by local biometrics. 6. **Report the bypass and its impact** — a biometric bypass on a banking or secrets app grants access to sensitive functionality without the biometric, a high-severity finding. ### Cheatsheet ``` biometrics implemented wrong = decorative (attacker with device bypasses w/o face/finger) two patterns EVENT-BASED (insecure): biometric API -> "success/fail" boolean -> CLIENT-SIDE code decides -> hook the check -> return success -> biometric SKIPPED entirely. BYPASSABLE. CRYPTOGRAPHIC (secure): biometric UNLOCKS A KEY in secure hardware (Keystore/Keychain/Secure Enclave) needed to decrypt/complete the operation -> bypassing check doesn't produce the key. CORRECT. KEY TEST (Frida/Objection): hook the biometric success callback -> force "success" bypasses auth + grants access? -> EVENT-BASED, insecure still can't proceed (needed a key)? -> cryptographic, correct objection -g explore (biometric bypass helpers) also check what it GATES: real secrets (biometric-bound key) vs just a UI gate (bypassable) server-side auth still enforced? (biometric unlocks LOCAL access, not a substitute for backend auth) tokens/creds protected (storage skill) ; secure fallback (PIN) LOCAL-AUTH-ONLY trust for critical access = bypassable -> server must enforce ``` ### Reading the implementation - **Hooking the biometric callback to "success" bypassing authentication** = event-based, insecure implementation; the biometric is a client-side boolean an attacker controls, so it grants access without any biometric. The core finding, and common. - **The app unable to proceed after a hooked "success"** (because it needed a key the biometric didn't unlock) = the cryptographic pattern done right; the biometric is bound to a key in secure hardware, so it can't be skipped. Note it as correct. - **Biometrics gating only a UI screen** (not protecting encrypted data) = a bypassable UI gate; the "protected" screen is shown/hidden by client code, not cryptographically locked. - **Local biometric auth relied on for security-critical access with no server enforcement** = trusting the client; a bypass grants access the backend should have independently gated. Sensitive operations need server-side auth. - **A high-value app (banking, secrets) with an event-based biometric bypass** = high-severity; access to sensitive functionality without the biometric. - **Cryptographically-bound biometrics unlocking a hardware key, with server-side auth for sensitive operations** = the secure state. ### The fix - **Bind biometrics to a cryptographic operation** — use the biometric to unlock a key in the secure hardware (Android Keystore with `setUserAuthenticationRequired`, iOS Keychain with biometric access control / Secure Enclave) that's *needed* to decrypt data or complete the operation. Never a simple client-side success boolean. - **Don't use event-based biometric checks** for anything security-relevant — they're bypassable by hooking the result. - **Enforce sensitive operations server-side** — the biometric unlocks local access, but the backend must independently authenticate; local auth isn't a substitute for server auth. - **Protect the fallback** (PIN/password) and the credentials/tokens the biometric gates (the storage skill). - **Assume the client is compromised** — biometrics improve UX and local protection but can't be the sole gate for critical access. ### Pitfalls - **Event-based biometric checks.** A client-side "success" boolean is bypassable by hooking; the biometric is decorative. Bind it to a cryptographic key operation instead. - **Gating a UI screen, not data.** Showing/hiding a screen based on biometric success is bypassable; cryptographically lock the actual data. - **Trusting local biometric auth alone for critical access.** It's bypassable with device control; sensitive operations must be server-authenticated. Biometrics complement, not replace, server auth. - **Insecure fallback.** A weak PIN fallback undermines a strong biometric; secure the whole flow. - **Treating the biometric as identity for the backend.** It authenticates locally to unlock access/keys; the server still needs its own authentication. ### References - OWASP MASTG (authentication, biometric testing) and MASVS - Android BiometricPrompt / Keystore (`setUserAuthenticationRequired`) and iOS LocalAuthentication / Keychain access control documentation - The insecure-data-storage, dynamic-instrumentation-frida, and mobile-api-traffic skills - OWASP mobile authentication guidance ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.