Security Best Practices

Learn more about FaceTec Security and best practices recommendations for keeping your implementation secure.

Security is #1, with Usability a Close Second

FaceTec is committed to providing a very high level of security in our customers' applications, and we believe that there are minimal thresholds that must be maintained to protect end users. To that end, FaceTec will not under any circumstances reduce security performance below our minimum thresholds and will always provide the best usability possible at these high security thresholds. FaceTec ships continuous AI enhancements and improvements to security and usability around every 2-4 weeks. FaceTec plans to make these consistent improvements for years to come, which is why it is important to keep up-to-date with our latest versions.

Keeping up-to-date with FaceTec SDK versions

To maintain optimal security in your application, the FaceTec (Device & Server) SDKs must be kept up to date. FaceTec is continually releasing algorithm improvements and important security features. Just as Apple, Google, and Microsoft patch their operating systems weekly to fix security-related behaviors, crashes, and UX problems, staying on the latest version of FaceTec SDK is an essential part of staying secure.

Has FaceTec SDK Security Been Tested by 3rd Parties?

Yes, FaceTec SDKs have been tested by many third-party organizations in multiple security sub-categories. The security of the Device SDKs is continuously tested by white-hat attackers who are participating in the Level 4 & 5 Attack Vectors of the $600,000 Spoof/Bypass Bounty Program.

Liveness Detection & Anti-Spoofing Algorithms

Liveness Detection is the single most important function of the FaceTec SDK. Liveness Detection strength is measured by the number of Spoofs that were able to bypass the system.

  • FaceTec is the only Face Verification company in the world to be Certified Level 1 & 2 by a NIST/NVLAP lab in an ISO 30107 PAD test. ~3,300 Attack Sessions were attempted by the NIST/NVLAP accredited testing lab.
  • FaceTec has had a Spoof Bounty Program since 2019, and has now blocked +130,000 Spoof attempts by white-hat hackers and security experts.
  • FaceTec's Liveness Detection accuracy has been thoroughly tested by our +90 Partners and by the development and security teams for hundreds of Apps and numerous State and Federal Governments.

Matching Algorithms

Matching Algorithms are important for many reasons. For Verification, the strength of the Matching Algorithm is important so that random impostors, siblings, or similar-looking individuals cannot access your account or identity.

Penetration Testing

Penetration testing assesses the strength of the product from a classic security perspective.

  • FaceTec's entire platform (Device + FaceTec Server) is tested every 12-18 months by Praetorian. In the latest test, zero critical, high, or medium risk behaviors currently exist in the product. An executive summary letter for this engagement is available upon request.
  • The FaceTec Device SDKs and FaceTec Server have all been blackbox & whitebox tested by Praetorian (160+ hours), and no method was found to tamper with Client-side code in order to get the Server to falsely respond with a Liveness Success.
  • Security of the Device SDKs is continuously tested by white-hat attackers who are participating in the Level 4 & 5 Attack Vectors of the $600,000 Spoof/Bypass Bounty Program.

FaceMap Tampering

FaceTec Device SDKs generate 3D FaceScans, which are encrypted and contain the data needed to perform Liveness Detection and Matching. It is critically important that FaceMaps cannot be tampered with once created.

  • The FaceTec 3D FaceScan encryption methodology has been verified (whitebox & blackbox) as tamper-proof by Praetorian.
  • FaceTec currently has an open Bounty if any 3rd party can demonstrate a successful crack a 3D FaceScan file.

No Honeypot Risk

Two types of data are required for every face verification: 3D Face Data for matching, and real-time 3D Liveness Data to prove the Face Data was collected from a live, present person. 3D Liveness Data must be timestamped, is valid only for a few minutes, and then can be deleted. New 3D Liveness Data must be collected for every subsequent FaceTec login.

Storing 3D FaceMaps does not create honeypot risk because they are “Face Data” without any Liveness Data, so they cannot be used to spoof FaceTec’s Liveness AI. Think of the stored 3D FaceMap as the Lock, and the User’s newly collected 3D FaceScan as a One-Time-Use Key that contains new 3D Liveness Data that proves that the Key has never been used before.

Camera Stream Tampering

  • The Browser SDK used in the $600,000 Spoof Bounty Program has been tested by Praetorian (160+ hours), and no method was found to tamper with our browser code or use a virtual cam that could make the FaceTec Server falsely respond with Liveness Success.
  • The Browser SDK has withstood 100% of thousands of Level 4 & 5 Attacks in the $600,000 Spoof Bounty Program.

FaceMap Encryption Keys

3D FaceMaps are encrypted using a combination of Asymmetric RSA Encryption and Randomized AES-256 Encryption. Usage of FaceMap Encryption Keys is required and enforced by FaceTec's Device SDKs and FaceTec Server APIs. Make sure to configure a new Private 3D FaceScan/FaceMap/IDScan Encryption Key, instead of using the Default Key that ships with the FaceTec Server.

FaceTec Server REST Endpoint Security

As shown in our configuration diagram, we REQUIRE that you ensure communication occurs with FaceTec Server via secure, SSL-enabled, internal server-to-server calls. Data should be passed to your own, existing web service via your own security best practices. Once the data has reached your server, you can communicate with the FaceTec Server via these REST endpoints.

Canary Process

FaceTec detects invalid 3D FaceScans and 3D FaceScan tampering, and will return a FaceTecError or a FaceTecLivenessResult when any tampering is detected. It is conceivable that an attacker may attempt a denial of service attack (DoS) on your API by sending your web service APIs malformed FaceMap data. FaceTec recommends implementing tools to monitor results and exceptions so your service remains unaffected by load increases caused by such attacks. Effective monitoring and siloing of your calls to the FaceTec Server is an effective mitigation strategy against conceivable scenarios where an attacker could attempt a denial-of-service attack.

Replay Attack Detection

To prevent replay attacks, FaceTec recommends maintaining a Hash Table of the 3D FaceScan/FaceMaps detected and processed over the lifetime of Your System. When a new 3D FaceScan is detected, Your System can perform a quick check in the Hash Table for the Hash Signature of the Incoming FaceScan. If Your System has seen this 3D FaceScan in past transactions (i.e. the Hash Signature is in the Hash table), then Your Team instantly knows that the incoming data is part of a Replay Attack.

The FaceTec Server already has this feature implemented. In most circumstances, Developers are encouraged to flag sessions that are Replay FaceMaps.

1:N Known Fraudster List

FaceTec SDKs ensure a Real, Live Human is presenting their 3D face to the camera. This means that if you ever determine a user to be fraudulent or otherwise a bad actor, you can store a database of these fraudsters' 3D FaceMaps. For each new user attempting to create an account, you can perform a 1:N Search against this 3D-DB of FaceMaps and flag new users who Match previously caught fraudsters at a very high probability. Funny faces and attempts to change/conceal the user's true 3D Face are also detected, or the session is rejected in almost all cases.

Using 1:N Search, you can permanently ban bad actors from your platform.

Usage of 3rd Party Libraries

FaceTec SDKs are closed-source and pre-compiled. Like most companies, FaceTec leverages numerous, well-established libraries as building blocks for certain computer vision, machine learning, security and obfuscation, and user interface tasks. For instance, OpenCV is an example of a thoroughly vetted library used by FaceTec for some tasks — “Along with well-established companies like Google, Yahoo, Microsoft, Intel, IBM, Sony, Honda, Toyota that employ the library, there are many startups such as Applied Minds, VideoSurf, and Zeitera, that make extensive use of OpenCV."

An exhaustive list of all libraries used by FaceTec is considered a trade secret and cannot be provided. All libraries used by FaceTec are thoroughly vetted and kept up-to-date by the FaceTec security team. FaceTec's shipped libraries are blackbox and/or whitebox penetration tested by Praetorian Cybersecurity Solutions.

FaceTec does not ship any other 3rd party libraries in a standalone fashion.

Security Scans, Static Code Scans, & Vulnerability Reports

Introduction and Strategy

FaceTec encourages all organizations that use its software to have a robust security strategy that includes frequent vulnerability scans and employs proactive defensive strategies. Vulnerability scans are an important way to ensure, via static analysis, that the infrastructure and dependent libraries remain secure.

Reporting Scan Results and Potential Vulnerabilities

For vulnerability scan questions or reports related to the FaceTec Device SDKs, please see the guidelines below before contacting FaceTec. Any vulnerabilities discovered in the client software and not related to the FaceTec SDKs are out of scope for FaceTec Support.

For vulnerability scans of FaceTec Servers, including FaceTec Containers, please see the guidelines below before contacting FaceTec. Investigating vulnerabilities on your servers or in (non-FaceTec) binaries in FaceTec Containers is likely out of scope for FaceTec Support.

Security Ownership

You are responsible for Patch Management on your own servers and containers. This includes FaceTec-related containers. If a potential vulnerability is flagged by a scan tool, and the vulnerability is in a non-FaceTec binary, it is your responsibility to assess and remediate if necessary.

Requirements for Submitting Behaviors Related to Vulnerability Scans

Before contacting FaceTec Support, please review these guidelines on submitting vulnerability scan results:

  • Please provide the specific possible vulnerabilities of concern and justification for each vulnerability as to why you believe these must be investigated by FaceTec. FaceTec will not parse vulnerability reports that contain potential vulnerabilities that are unrelated to FaceTec binaries.
  • Please confirm that you understand that FaceTec does not require a specific version or Linux distribution and that you must ensure that your systems are patched and that non-FaceTec vulnerabilities must be assessed and remediated by you.
  • Please provide the full scan report.
  • FaceTec must be able to reproduce the results. You must provide full steps to reproduce the report, including what software you are using, what you are scanning, versions, and any other related configurations. Please see the Technical Support Overview for more information.

Requirements for Submitting Behaviors Related to Other Static Code Scans or Reports from 3rd Party Tools (Static Code Analyzers, IDE Scan Tools, etc.)

Before contacting FaceTec Support, please review these guidelines on submitting vulnerability scan results:

  • For all reports, full steps to reproduce the behavior must be provided, including expected behavior and actual results.
  • For leak detection reports, you must provide results from a leak detector or otherwise prove that there is a real leak. Oftentimes, false leaks are flagged when the behavior is actually your own code holding onto references to FaceTec objects.
  • For leak detection reports, you must provide the size of the leaked object(s), as well as how often that memory is leaked.

Client-Side App Protection

Your App should use technologies like iXGuard (iOS), DexGuard (Android), and JSScrambler (Browser) to improve the security of your application by preventing disassembly and reverse engineering. These tools and others like them detect, prevent, and/or provide root detection, breakpoint detection, code injection, and App binary tampering.

Some of these tools are constantly evolving and can even be configured to alert you when your app is being hacked or tampered with.

Static Analysis & Fuzzing

FaceTec uses state-of-the-art static analyzers to find potential behaviors in the FaceTec code. FaceTec uses specialized fuzz testing tools to attempt to find data inputs that can induce bad behavior in the FaceTec SDKs.

FaceTec's libraries have also been scanned and fuzz tested by many of our Partners & Customers and their security teams. All behaviors are investigated with high priority, and zero known behaviors currently exist.

Content Security Policies (Browser)

Your web app should make appropriate use of CSPs to ensure that malicious scripts are not injected into the execution context of your browser app.

Additional Encryption

3D FaceScan/Maps and Audit Trail Images are just data. If you have additional security concerns or requirements, you may apply additional encryption to this data based on your additional requirements. Also, if you would like to change how the FaceTec Server loads the Private Key, you are free to customize this to your requirements.

Match Scores, Liveness Scores, Lighting, Glare Scores, Retry Screen Guidance & Hill Climbing

In Security, a Hill Climbing Attack is any type of attack where an attacker leverages a targeted software's responses to gain knowledge about the system that allows them to better understand and/or bypass its underlying security layers. FaceTec has taken specific steps to prevent these Hill Climbing Attacks.

For 3D Liveness, the FaceTec UI does not provide Liveness Scores, granular API Flags, or the type of guidance that can assist attackers in understanding why their attack may have failed. 3D Liveness succeeds for ~99% of motivated, real first-time users on their preferred device, and as such, the inclusion of these would not provide for a better User Experience.

For 3D:3D Matching, FaceTec provides generalized Match Levels, but does not provide specific scores or flags to explain why a Session was not processed successfully.

Providing such Scores/Flags would allow attackers to determine if artifacts are getting "closer or further from" succeeding and would be detrimental to overall security.