Client-Side Security Myths & Discussion

Learn about client-side security and how FaceTec provides superior security to on-device re-verification methods.

The Fundamental Question: "Can you ever trust Client-Side Security 100%?"

The Answer: No, and no matter what anyone tells you, security can never be guaranteed when a Bad Actor has physical or remote control of a device. Even if the device were to run "Passive Liveness Server Software,” there is still no means for the device to determine if the images/videos have been injected rather than captured in Real-Time by a Real-User (known as a 1st Generation source).

Because FaceTec cannot trust Client-Side Security alone, FaceTec uses its own Proprietary Technology and Security Checks to ensure that the Device has not been compromised, rooted, infected with malware, or controlled by a Bad Actor. This prevents Bad Actors and Fraudsters from using Tampered Devices in Unsecure Environments to pass a 3D Liveness Check with FaceTec's Software.

See the Security Best Practices page to learn more about how FaceTec uses proprietary Level 4 & 5 Payload Anti-Tampering and Camera Anti-Injection Checks to protect against Client-Side vulnerabilities.

Myth 1: "On-Device Biometrics Are the Only Way to Ensure Images Are not Stolen & Leveraged Against the User."

Reality: On-device biometric storage is blind to alternative access points and can be circumvented altogether.

On-device biometrics weakly link a User to their device, whereas Server-Side biometrics permanently bind the User to their account. If a phone’s on-device, biometric lock can be circumvented by using a PIN Code, then anyone with that PIN Code can take complete control of the device. This includes the ability to overwrite any on-device biometric data. This is why it is troubling that FIDO continues to incorrectly promote on-device hardware as a secure means of storing biometric data. This is a dangerous misconception on FIDO's part, especially since we have already developed a proven means of safeguarding biometric data through 3D Liveness Detection.

Myth 2: "Trusted Execution Environments (TEEs) or Secure Enclaves Solve On-Device Security Problems."

Reality: A chain is only as strong as its weakest link. The same logic can be applied to device security. Since a PIN Code can be used as a backdoor to a device, it can also be used to overwrite stored biometric data. This results in on-device “Liveness” being as secure as a simple 4 to 6-digit PIN Code.  It is important to note that any on-device storage method can be breached when a Bad Actor gains physical access to it. Thus, the real problem is not where the data is stored; it is whether or not that confidential data should even be stored.

A common misconception is that TEEs prevent Bad Actors from “result flipping” (flipping the result to the hacker’s desired outcome by modifying data, running arbitrary code, and changing variable values). TEEs cannot prevent this for the following reasons:

  • TEEs do not actually run any biometrics algorithms; they can only encrypt/decrypt data.
  • TEEs are device/platform specific. Even if they prevented results from being “flipped”, special code would need to be written for every unique combination of device and software platform.
  • At some point, the stack will reach code that is in a non-TEE environment. At this point, the system is vulnerable to “flipping.”
  • TEEs themselves can be attacked –

However, the “result flipping” problem can be solved if the server requires each new capture session to include time-stamped, one-time use Liveness Data for Re-Verification.  As the Liveness Data itself is never stored, the associated biometric cannot be reused in the case of a leak.

Myth 3: "Fido Certified" Means Secure.

Reality: FIDO Certification largely focuses on communication protocols and only fulfills the weakest of requirements when it comes to their “biometric certification” for Liveness.

A valid FIDO-certified product can be as simple as a button being pressed. FIDO mostly concerns itself with the communication protocols used to securely communicate between an app and another party. However, these communication protocols alone cannot make an app 100% secure.

FIDO’s “biometric certification" for Liveness has a surprisingly low pass threshold: 1 in 5 spoofs are allowed to bypass the system’s Liveness Check. This results in a false positive rate as high as 20%, which is nowhere near the acceptable failure rate allowed in the Certifications FaceTec has earned from NIST/NVLAB in its 30107-3 PAD tests.

Therefore, “FIDO Certified” should not be interpreted as a device being secure.  For instance, the Samsung Galaxy S10 became the first FIDO PAD-certified fingerprint reader to be certified by FIDO; it also became the first FIDO-certified authenticator to be publicly spoofed just days after its release. To see why “Liveness” plays a much more significant role in making a device secure, please see www.Liveness.com for more information.

Myth 4: "Browser Apps are Inherently Less Secure Than Native iOS/Android Apps"

Reality: Browser-based and Native Apps are still subject to the same genres of attacks. iOS/Android Apps only provide a layer of obfuscation.

Specifically, native iOS/Android apps are just as easily decompiled. They can have breakpoints set, values modified, and variables read just as easily as Browser Apps.

  • In the Browser, Dev Tools are built into the Browsers themselves, which does provide a level of convenience for a Bad Actor.
  • However, iOS & Android only provide a layer of obfuscation. While forcing an attacker “to learn different tools” can increase the effort involved in hacking, it does not make the platforms more secure. Once an attacker is familiar with the specific tools for iOS & Android, this layer of obfuscation can be bypassed as well.

Do you still doubt a browser can be secure? Then try beating FaceTec's Browser Security! You can give it your best shot by participating in FaceTec's $600,000 Spoof/Bypass Bounty Program.

Myth 5: "Active" & "Random" Liveness Detection Provides Tangible Security Benefits.

Reality: “Active” & “Random” Liveness Detection only results in an additional layer of protection with its own set of workarounds. Bad Actors can still manipulate devices to signal the correct user responses, especially since these responses are not usually captured concurrently with the data necessary for Matching to the correct user. Call and response mechanisms similarly add extra friction for real users without providing much in the way of real security benefits.

Examples of “Active” & “Random” Liveness Detection:

  • Users’ eyes must follow a bouncing ball as it takes a random path around the screen.
  • Users must perform an action, like blink, smile, or look over their right shoulder.
  • Client-side code reads reflections from a flashing light/color.

Workarounds:

These random actions only add a weak layer of protection with their own set of workarounds. A hacker who has reverse-engineered the App and has root access to the device can manipulate code, inject videos, control puppets, or programmatically bypass on-device checks. Additionally, complicit fraudulent users can provide a bad actor with their biometric data to bypass this layer of protection.