Common Mobile Security Questions and Answers


Product: HYPR Android/iOS SDK/App

Applicable Version(s): All


  1. How does the initial authentication flow work for native mobile applications (i.e., when users must be authenticated to access the native mobile application)?

    • User is prompted to authenticate with their authenticator (TouchID/FaceID/PIN, etc.)
    • User authenticates
    • User is logged in
  2. How are two strong factors established during initial authentication to allow users to authenticate with multiple factors?

    • Users go through FIDO enrollment, where they are asked to register via TouchID/FaceID/PIN, etc.; the authenticators with which the users register are specified in the FIDO policy, which is configurable from the Control Center
  3. What ability do you have for first time setup for a native mobile application for users who are mobile only but still require two strong factors?

    • QR Code
    • Magic Link 
    • Registering with the JSON Content that the QR Code represents
  4. How do you prevent unauthorised use of any externally facing API endpoints?

    • All APIs require a valid access token

  5. What ability do you have to allow users to authenticate into a native mobile application while the device has no Internet connectivity?

    • We have offline authentication which leverages a cached authentication payload.

  6. Do you have a flow to bring the user back online when the device re-establishes Internet connectivity?

    • There is no need for such a flow. Typically it would be a conditional where if there is internet access then you will perform the online authentication, otherwise, perform the offline authentication.

  7. What ability does the solution provide to allow encryption keys to be generated from the authentication factors being used?   (Encrypted data at rest should only be accessible when the user has authenticated both for online and offline authentication.  The result of a successful authentication challenge should provide consistent secure material which can be used to generate a key encryption key.  i.e. for username+password flow PBKDF2 can be used to generate this material.  There needs to be a consistent mechanism for all factors used.)

    • Assuming the question is the following: I have FIDO registered authenticators. I want to protect the generation of encryption keys with these FIDO authenticators i.e. the user must FIDO authenticate in order to access/use these keys 

  8. Does the solution perform any device fingerprinting to ensure the application is still running on the same device that was originally/firstly setup?

    • We do not perform device fingerprinting; we generate a unique identifier per app installation.

  9. Are there any exceptions or special cases we should know about for the different Android manufacturers when using your solution?

    • Samsung OS 9 devices with the native Face authenticator should not be able to use the Native Face authenticator within an app due to restrictions here:

      Samsung has bypassed this restriction and allowed for Native Face Authenticators to work on Android OS 9 device, which leads to unexpected behavior as Android does not expect this

    • Using OnePlus2, OnePlus3, OnePlus3T, OnePlusX, the fingerprint authenticator might not accept the user’s fingerprint

  10. How quickly and easily can an authentication method be disabled if already in use with our mobile applications (i.e., disable FaceID but leave TouchID still working for the application already being used in production)?

    • You can disable it by removing it from the Control Center policy, accessible via the web browser

  11. If a new factor of authentication (i.e., a new biometric sensor) is introduced, what is the process to make this available for use on devices which support it?

    • Android: Native authenticators will be covered by Android’s Biometric Prompt, which handles native authenticators; as soon as Android supports it, it will be supported

    • iOS: Dependent upon the API changes involved for the new authenticator 

  12. Do you perform any integrity checks on the devices where the solution is running (Jailbreak/root, etc.)?

    • HYPR performs the following checks:

      • Android: Root Detection

      • OS: Jailbreak detection is performed by Guardsquare iXGuard

    • How are checks controlled and monitored?

      • Android: Root detection is initiated upon HYPR SDK initialization

      • iOS: We delegate the monitoring/control to iXGuard’s jailbreak detection where they injected 250 checks into the SDK and we’ve explicitly included around 15 other checks in the SDK

    • What actions are taken by the solution if the integrity checks fail?

      • Android: Default behavior is a dialog appears informing the user that the device is rooted. There is no way for the user to get past this dialog. The SDK also has a configuration to have the app crash upon root detection.

      • iOS: The app does not function

  13. Does your solution implement any binary protection mechanisms?

    • Root detection

    • Obfuscation

  14. Does the solution provide APIs which are consistent with Google/Apple coding guidelines to support both Kotlin and Swift respectively?

    • We support Kotlin and Swift

  15. Is the SDK enabled for bitcode?

    • Yes

  16. Does the solution support Android Application Bundles (AABs)?

    • You will be able to create an AAB; jailbreak detection works as long as HyprApp.initializeApp() is used

  17. Does the solution provide the ability for single sign-on (SSO) across applications from the same developer account, i.e., authentication into App A; Launch App B; and be automatically logged in because App A was recently accessed?

    • If an IDP is used (Okta, Auth0, Azure, etc.) then we could have a mobile initiated way of authenticating into other apps via the OIDC access token. 

Version Date Comment
Current Version (v. 3) Apr 14, 2022 15:33 Khedron de León
v. 2 Feb 23, 2022 18:49 Russ Rezepov
v. 1 Oct 30, 2021 16:58 Edward Poon
Was this article helpful?
0 out of 0 found this helpful