/
Contact usSee pricingStart building
    Overview
    iOS SDK reference
    Android SDK reference

    React Native SDK reference

    Installation
    Changelog
    Configuration
    Pre-built UI
      UI Configuration
    Users
      Get user
      Update user
      Delete authentication factors
    Email Magic Links
      Send
      Login or create
      Authenticate
    OAuth
      Start
      Authenticate
    Passwords
      Create
      Authenticate
      Reset by Email Start
      Reset by Email
      Strength Check
    One-time Passcodes (OTP)
      Login or create via SMS
      Send via SMS
      Login or create via Email
      Send via Email
      Login or create via WhatsApp
      Send via WhatsApp
      Authenticate
    Time-Based One-Time Passcodes (TOTP)
      Create
      Authenticate
      Get Recovery Codes
      Recover
    Session Management
      Get Session
      Authenticate Session
      Revoke Session
      Update Session
      Get Tokens
    Passkeys & WebAuthn
      Register
      Authenticate
      Update
    Biometrics
      Introduction
      Register
      Authenticate
      Keystore available
      Registration available
      Remove registration
      Get sensor
      Errors
    Device Fingerprinting
      Get telemetry ID
    More Resources
      SWR & caching
      Deep linking
      Android KeyStore considerations
Get support on SlackVisit our developer forum

Contact us

Consumer Authentication

/

Mobile SDKs

/

React Native SDK reference

/

More Resources

/

Android KeyStore considerations

Android KeyStore considerations

When a user registers a biometric factor with Stytch, our SDKs rely on the device keystore to securely store sensitive data associated with the authentication factor.

Unfortunately, Android KeyStore has had significant functionality and reliability issues throughout its lifespan in the Android ecosystem. Not all devices that support biometrics have suitable Keystore implementations that can be relied on.

The official Tink documentation references this instability (1, 2) and they have provided developers with a mechanism to ensure the device you're operating will not encounter implementation problems (3).

If KeyStore is found to be unreliable, this code will fall back to storing sensitive information in the application sandbox, as opposed to the KeyStore. This is not itself a security vulnerability, as the Android platform enforces access barriers between applications to prevent unauthorized access to your application's private data.

That said, this method comes with less security guarantees than using KeyStore, such as protecting the data in the event of a privilege escalation in Android. There are some things you should watch out for when developing an application that allows this fallback.

The biggest issue which would potentially expose your application's sandbox data is writing insecure IPC (inter-process communication). Developers can accidentally create an arbitrary file read vulnerability by misusing Android IPC (4), or by writing sensitive information to public storage (sdcard). Be extra cautious with any functionality that accepts arbitrary file paths as arguments, which may allow an attacker to redirect the flow of data to an area they can access it.