Authentication and Registration
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?
Yes, HYPR supports SSO with the use of HYPRspeed.
How does the initial authentication flow work for native mobile applications (i.e., when users must be authenticated to access the native mobile application)?
The user is prompted to authenticate with their authenticator (TouchID/Fingerprint/PIN, etc.). The user authenticates, and is logged in.
How are two strong factors established during initial authentication to allow users to authenticate with multiple factors?
The authenticators (methods such as TouchID/Fingerprint/PIN, etc.) with which the users must register are specified in the policies, which are configurable from the Control Center. Users go through FIDO enrollment to register via the prescribed methods, depending on the applicable policies.
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?
HYPR offers three core methods of pairing the HYPR Mobile App:
- Magic Link: a link sent to the user which takes them to HYPR Device Manager for pairing or login
- QR Code: Scan a HYPR QR Code to pair your phone with a HYPR-enabled Application
- JSON: JSON content (part of the the QR payload) used to install a pre-paired Passwordless client
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 Mode authentication which leverages a cached authentication payload.
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, provided the user has already paired with HYPR at least once from the device. Paired devices are capable of Offline Mode authentication.
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 must 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.
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.
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.
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 is dependent upon the API changes involved for the new authenticator.
What happens if I lose my phone?
If you are without your phone for some reason, contact your admin.
Think of today's lost phone as yesterday's forgotten password. When you forgot your password, you called your office help desk to make the necessary arrangements for access.
If you lose, misplace, or forget your phone, your admin will issue you a temporary access method (e.g., a recovery PIN, smartphone, security token, or smart card, depending on your policy). If your phone is truly lost, your admin will also revoke any access associated with the lost device.
What happens if I get a new phone?
To enroll a new smartphone:
- Open the HYPR Workforce Access Client on your desktop or the HYPR Device Manager application in your SSO landing page.
- Choose the option to pair a new device. Follow the instructions for the method you are using:
Do you perform any integrity checks on the devices running the solution (Jailbreak/root, etc.)?
- Android performs root detection initiated at the same time as the SDK initialization. The default behavior generates a dialog 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 HYPR Mobile App crash upon root detection.
- iOS jailbreak detection is performed by Guardsquare iXGuard. We delegate the monitoring/ control to iXGuard’s jailbreak detection; they inject 250 checks into the SDK, and HYPR explicitly includes other checks in the SDK. If the integrity checks fail, the app does not function.
Does your solution implement any binary protection mechanisms?
- Root detection
How do you prevent unauthorized use of any externally facing API endpoints?
All APIs require a valid access token.
HYPR for IOS
Is the SDK enabled for bitcode?
HYPR for Android
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.
Does HYPR Support Android Go?
Android (Go edition) is a lightweight version of Android built to provide entry level smartphones such as those which may contain less than 2 gigabytes of RAM, and less storage space for media content. Android Go is available on over 1600 device models from many local manufacturers and may be tailored to individual manufacturer needs.
Many of these devices may have limited support for certain cryptographic capabilities or security requirements and performance needs related to the use of HYPR services. HYPR provides limited support for Android Go as a result, and while some Android Go devices will work out of the box, others may be unable to use with the HYPR app.
Does HYPR support iris recognition and/or facial recognition on Samsung Devices?
Yes. HYPR's Native Authenticator functionality supports enrolling biometric authenticators that use Android's biometric API. For Samsung devices, this means the following:
Samsung Galaxy S8: Face recognition and Iris recognition are not supported in HYPR
Samsung Galaxy S9: Face recognition, Iris recognition, and "Intelligent Scan" are supported in HYPR as of Android 10
Samsung Galaxy S10: Face recognition is supported as of Android 10 in HYPR. Iris recognition was dropped from the Galaxy S10
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.
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.
|Current Version (v. 4)
|Apr 12, 2023 09:41
|Khedron de León
|Apr 14, 2022 15:33
|Khedron de León
|Feb 23, 2022 18:49
|Oct 30, 2021 16:58