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.