Replace Your Authentication System with Face Recognition using FACEIO's fio.js, & Tailwind.css

In the realm of web development, user authentication has traditionally been dominated by username and password combinations. However, with advancements in biometric technologies, face recognition is emerging as a more secure and user-friendly alternative. This article delves into the integration of FACEIO, a cutting-edge face recognition platform, into web applications, offering a step-by-step guide to replace traditional login methods with facial authentication.

Why Choose Face Recognition Authentication?

Face recognition authentication offers several advantages over traditional methods:

1. Enhanced Security: Unlike passwords, which can be guessed or stolen, facial features are unique to each individual, making it much harder to impersonate a user.
2. Improved User Experience: Users can access their accounts quickly and effortlessly without the need to remember passwords.
3. Reduced Fraud Risk: Face recognition reduces the risk of phishing and other social engineering attacks.

Now, the Details:

FACEIO is a cross-browser, Cloud & On-Premise deployable, facial authentication framework, with a client-side JavaScript library (fio.js) that integrates seamlessly with any website or web application desiring to offer secure facial recognition experience to their users.

Put it simply, FACEIO is the easiest way to add passwordless authentication to web sites or applications. Simply implement fio.js on your website, and you will be able to instantly authenticate your existing users, and enroll new ones via Face Recognition using their computer Webcam or smartphone frontal camera on their favorite browser.

Some Nice FACEIO Features

• Highest security standards. Privacy by design with maximum user convenience.
• No requirements for biometric sensor.
• Authenticates and confirms identity of users instantly without FIDO keys, OTP codes, or security questions. Refer to the
• Full cross-browser compatibility (Chrome, Firefox, Safari, Edge & Chromium derivatives).
• Zero external dependency. Only standard technology implemented in plain JavaScript & CSS.
• Defense grade accuracy with less than 100 milliseconds recognition speed powered by state-of-the-art facial recognition engines.

FACEIO works with regular Webcams or smartphones frontal camera on all modern browsers, does not require biometric sensors to be available on the client side, and works seemingly with all websites and web-based applications regardless of the underlying front-end JavaScript framework or server-side language or technology.

Implementing FACEIO on your web application

Integrating FACEIO on your website or web application is straightforward regardless of the underlying JavaScript framework whether it is React., Vue.js, Next.js or even Vanilla JS.
Before so, you need to create a new application first on the FACEIO Console, and link this resource to your website or web application. The checklist below highlights the steps to follow for a smooth integration of
fio.js on your website or app:

1. Create a new FACEIO application first: Follow the Application Wizard on the FACEIO Console to create your first application and link it to your website or web application.
2. The Application Wizard should automate the creation process for you. Usually, this involve inputting an application name, selecting a facial recognition engine, cloud storage region, reviewing security options, customizing the Widget layout, and so forth...
3. Once your first FACEIO application created, simply implement fio.js, our facial recognition JavaScript library on your website, and initialize the library with your application Public ID.
4. Congratulations 👏. You have FACEIO up & running! Now, it's time to enroll() and authenticate() your first user via face recognition as we will see on the HTML boilerplate..

The HTML Integration Boilerplate

Understand the fundamentals

• To enroll (register) a new user, simply call the enroll() method from the recently instantiated faceIO object. The enroll() method let you transactionally enroll new users on your application. A process better known as on-boarding. It is the equivalent implementation of a standard register/sign-up function in a traditional password managed, authentication system. This is done on line 31 of the gist above.
• Effective call to enroll(), will trigger the FACEIO Widget, ask for user’s consent (if not yet authorized), request access (if not yet granted) to the browser’s Webcam/Frontal camera stream, and finally extract & index the facial features of the enrolled user for future authentication purposes.
• enroll() takes a number of Optional Parameters including locale for the interaction language, permissionTimeout which correspond to the number of seconds to wait for the user to grant camera access permission, but more importantly, enroll() accept a payload which simply put, an arbitrary set of data you can link to this particular user such as an Email Address, Name, ID, etc. This payload will be forwarded back to you upon successful future authentication of this particular user.

👉 The enroll() method, its expected parameters, Promise fulfillment, error handling, etc. are officially documented here.

• To Authenticate & Recognize a previously enrolled user, simply call the authenticate() method from the recently instantiated faceIO object. The authenticate() method let you transactionally authenticate (recognize) previously enrolled users on your application. It is the equivalent implementation of a standard login/sign-in function in a traditional password managed, authentication system.
• authenticate() returns a Promise whose fulfillment handler receives a userData object when the user has successfully been identified. The most important fields of this object are: payload, which is the arbitrary data you have already linked (if any) to this particular user during his enrollment via the payload parameter, the enroll() method takes, and Facial ID, which is an Universally Unique Identifier assigned to this particular user during his enrollment. This Facial ID alongside the payload data could serve as a lookup key on your backend to fetch data linked to this particular user on each future successful authentication for example.

👉 The authenticate() method, its expected parameters, Promise fulfillment, error handling, etc. are officially documented here.

Best Practices and Considerations

Integrating FACEIO for face recognition authentication offers a blend of enhanced security and user convenience. As web technologies evolve, embracing such innovative authentication methods can significantly improve user experience while maintaining high security standards.

• Security Best Practices: This guideline presents several best practices that have a significant, positive impact on your FACEIO application's security.
• Privacy Best Practices: This guideline presents several best practices that have a significant, positive impact on your FACEIO application's privacy practices.

Further Reading

It’s super quick to implement FACEIO, and get it up & running on your website or web application. The following tutorials, and guides should help you get started with FACEIO:

• Getting Started Tutorial: Learn the fundamentals. Your first steps with FACEIO...
• Integration Guide: Learn how to implement fio.js, our facial recognition library on your website before rolling facial authentication to your audience...
• Developer Center: Code samples, documentation, support channels, and all the resources you need to implement FACEIO on your website...
• Frequently Asked Questions: Get instant answers to the most common questions.

Community Contributed Tutorials

The following, high-content, community contributed guides & tutorials should help you implement fio.js on your web or mobile application using your favorite JavaScript framework whether it is React, Vue, Angular, Next, React or Vanilla JavaScript:

• Official NPM Package for FACEIO
• Facial Authentication with FACEIO & HTMX
• FACEIO Community Forum - Find answers to the most common questions
• Implement a Facial Recognition Authentication System Using React.js & Tailwind
• Integrating FACEIO into a React Web Application with Tailwind CSS
• Building Face Authentication in React with FaceIO and Bootstrap 5

Comments

[Michael K]

While this is an interesting approach to authentication, I am convinced that it is completely insecure and not very private and should not be used under any circumstances. In fact, I am convinced that the entire approach of implementing passwordless authentication without biometric sensors is inherently flawed and cannot result in any secure or private authentication. Instead, you should use Passkeys (an upcoming technology implemented by all major browsers and operating systems) or stick to tried-and-true strategies (i.e. long, salted, and hashed passwords).

I realize that these are hefty claims (hefty enough that they made me create an account here just to write this comment), so I will back them up thoroughly. I will be comparing Faceio to Passkeys, as all the issues I see in Faceio are not present in Passkeys and the comparison seems handy.

1. Spoofing - You cannot possibly fully prevent face spoofing. Even if the chosen algorithm is 100% accurate in recognizing another screen being held up to the webcam, the webcam itself can be spoofed. A user can always just plug in an external web cam (or basically a video player that pretends to be a webcam) and there's nothing you can do about it. Biometric sensors circumvent this by having integrated cryptography that is able to sign the payload along with a certificate that lets you, the relying party, verify that a trusted authenticator was used (see this section of the WebAuthn spec - Passkeys basically just implement WebAuthn). Let's use an iPhone, for example. Apple produces the Secure Enclave that is in charge of FaceID and provides it with a private-public key pair and a corresponding certificate. Then, when FaceID is used, it can say "here's the result, I'll sign it for you and here's Apple's certificate that proves I'm not some webcam impostor". Webcams don't have that.
2. Replay attacks - This approach cannot have any proper protection against replay attacks. The reason for this is that there is no API that allows you to have the webcam sign a challenge that you provide, which means that the webcam output can be replayed without you doing anything about it. With passkeys, the relying party (the app's backend server) comes up with a fresh challenge that's valid for just a brief moment and the iPhone's secure enclave then cryptographically signs that challenge and attaches that to the actual authentication response. This way the relying party is assured that the Secure Enclave produced the result just now, for this exact request.
3. Privacy - since the face is the only means of identifying a user in Faceio, it must be generally possible to take any person's face, compute the value to query Faceio with and then see if the person has an account. Users cannot achieve repudiability for their accounts.

These issues show that the actual facial recognition can easily be circumvented, reducing your authentication to nothing but the PIN. Sadly, you have chosen to make the PIN only 4 to 16 digits. Due to low memorability of numbers and familiarity with 4-digit PINs, I would assume many users would only use 4 digits, thus reducing their security to about 10 bits of entropy. For reference, NIST recommends that user-chosen memorized secrets be no less than 8 printing ASCII characters, resulting in a minimum of about 52 bits of entropy. Please not that the security grows exponentially here.

What makes matters worse, is that you advertise a "PIN uniqueness enforcing" feature. This means that you must be storing your PINs without a salt, leaving you vulnerable to rainbow or dictionary attacks in the event of a data breach. Even if you don't consider this in your risk model (which I personally would consider highly irresponsible), this is against basically every recommendation out there (e.g. NIST).

Another big red flag is that the linked NPM package just downloads a script from some CDN. I don't see how Faceio could be run on-premises as advertised under this circumstance.

All in all, I cannot emphasize enough how badly suited this is for actual authentication. Webcam-based face recognition is fine for convenience features, but definitely not for security.

[Vincent]

Hi Michael,

Applications security isn’t a feature or a benefit – it is a bare necessity. Please take a look at the FACEIO Security Center for additional information about the set of security mechanisms implemented by FACEIO including but not limited to: Face Anti Spoofing & Deep Fake Prevention, Minors Access Restriction, Strong PIN Code Enforcements, and so on...

Now, the long answer:
It's important to have open discussions about the security and privacy implications of any authentication technology. I'd like to address some of the points you've raised:

• Spoofing and Webcam Security: You're correct in highlighting the challenges of preventing face spoofing. FACEIO implements several measures to mitigate these risks, such as rejecting weak PIN codes, preventing duplicate enrollments, and protecting against deepfakes and face spoof attempts.
• Replay Attacks: The risk of replay attacks is a concern for many authentication systems, not just facial recognition. FACEIO's approach, which includes the use of unique PIN codes and other security measures, aims to mitigate this risk.
• Privacy Concerns: FACEIO's use of facial recognition does raise privacy considerations. However, it's important to note that the technology is designed with user consent and data protection in mind. Users have control over their data, and FACEIO complies with privacy regulations to ensure user data is handled responsibly.
• PIN Security: The concern about the entropy of 4-digit PINs is understandable. FACEIO allows PINs up to 16 digits, encouraging users to opt for longer PINs for increased security. The system also rejects common and weak PIN patterns. Regarding the "PIN uniqueness enforcing" feature, it's important to clarify that this doesn't necessarily imply the absence of proper salting and hashing of PINs. Secure practices can still be maintained while ensuring PIN uniqueness.
• Implementation and On-Premises Deployment: The use of a CDN for script delivery is common in many web applications for efficiency and scalability. This doesn't inherently conflict with FACEIO's claim of on-premises deployment capabilities, as core processing and data storage can still be managed locally.

In conclusion, while FACEIO, like any authentication system, has areas that could be improved, it incorporates several robust security measures. It's also important to remember that no single authentication method is universally superior; the choice often depends on the specific requirements and context of the application.

[Michael K]

Hi Vincent,

thanks for your prompt response. Sadly, however, I don't feel like it properly addresses any of the issues I raised.

1. You say that you measures against face spoofing include "rejecting weak PIN codes, preventing duplicate enrollments, and protecting against deepfakes and face spoof attempts". The first two don't do anything against face spoofing! They are perhaps additional layers of security, but they don't stop users from spoofing faces. And in fact, this is exactly what I said originally: "facial recognition can easily be circumvented, reducing your authentication to nothing but the PIN".

You of course also mention "protecting against deepfakes and face spoof attempts", linking to a PDF. There, however, you only talk about deepfakes or attacks where other media are held against the camera. Therefore, this paragraph completely fails to respond to my outlined attack of spoofing an entire webcam, basically choosing the output video signal from some MP4 instead of holding media to the camera.

1. PINs are not a defense against replay attacks, they are a factor of authentication (knowledge). Replay attacks are usually prevented by having the other party cryptographically sign a fresh challenge. However, I realize that this entire attack kind of relies being able to spoof the webcam signal, so I'd say we can consolidate this under point 1.
2. I understand that the system may be consent-based, but getting user consent doesn't automatically make a system private. The issue that I have here is that anyone would be able to take someone else's face data and figure out if that person is registered to the database. Since face's don't tend to change, there's nothing that users can do about it. In contrast, with Passkeys, the IAM provider only stores some Passkey ID and a public key. This data cannot be directly associated with any person. If I delete all traces of this Passkey from my devices, nobody will be able to prove (without use of other information, e.g. network logs) that I ever had an account.
3. You claim that uniqueness enforcing doesn't mean the absence of other security best practices, including salting. I highly doubt that, and OWASP backs me up: "Finally, salting means that it is impossible to determine whether two users have the same password without cracking the hashes".

The issue with this is that, given read access to your database, I could just iterate over all 10.000 4-digit PINs and check if any other account uses that PIN. This means I can search the PIN-space once to crack all the PINs instead of having to search it once per PIN, drastically increasing the cost of this attack.

But I always love to learn and so I'd be thankful to you explaining to me how you can implement uniqueness checks without becoming vulnerable to this type of attack. So please, in the interest of Kerckhoffs's principle, I'd love you to share how exactly you save PINs on the server and how they can be checked for uniqueness and yet be secure.

1. Regarding on-premises deployment, I disagree. Having the npm package be designed like this means that every client that uses Faceio must add a CORS exception for your CDN, even if the actual data processing runs elsewhere. This may be considered a security risk. It also takes away authority from developers over the code contained in their application.

I agree with your statement that "no single authentication method is universally superior". However, I still strongly believe that the face detection part of Faceio provides no real security and can only act as a fancy way to enter a username. The PIN is what provides actual security, but I have laid out multiple reasons for why its security is not sufficient in my eyes.

I also take issue with your approach to making certain security features a paid upgrade or opt-in (as stated in the PDF you linked to about face spoofing detection: "Recognizing the premium value of this advanced security feature, PixLab has made it exclusively available starting from the Business Plan tier"). While this is not an issue unique to Faceio, I find that this approach stands in contradiction to your statement that "Applications security isn’t a feature or a benefit – it is a bare necessity".

Finally, I find it quite worrying that your TOS prohibit users from testing for vulnerabilities (otherwise I would have attempted to practically verify the possibility of webcam spoofing) and even forbid users to "decipher, decompile, disassemble or reverse engineer" any of the software. This grossly contradicts Kerckhoffs's principle and especially considering you're providing a security product, such wording should not be present in your TOS.

[Vincent]

Hi Michael,

There is no central database under FACEIO. Each application is sandboxed and AES 128 encrypted using its own private key. PINs, application private data is stored on this encrypted index similar on how iOS apps are sandboxed. You can learn more about the sandbox mechanism via faceio.net/facialid#facial-vector. Even if you guess the PIN of someone else, you won't get nothing except his facial hash which is an array of floating point numbers. The data is meaningless on its own, effectively acting as a hash, and cannot be reverse engineered.

Finally, OKTA, a traditional authentication provider has been hacked, and exposed all its customer data...

[Michael K]

Hey Vincent,

what you wrote does not respond to any of my arguments. Furthermore, I don't understand how any of what you mentioned would contribute to security significantly. Sure, encryption and sandboxing are nice, but someone has to manage the key and given that I couldn't find anything about these keys in your docs, I'm going to assume they're managed by you, meaning this provides only little security in the event that you are breached. Also, your first link points nowhere.

I also don't understand how guessing somebody's pin would give you their facial vectors. I mean sure, if PINs are unique you can find the user's entry in the database (again: thanks to a lack of proper salting - otherwise this would have to be a brute force attack), but this is not an attack vector that I'm concerned about. Also, the facial vectors may not be sufficient to reconstruct a face, but they are what the facial authentication is derived from, so they do carry value (especially if they only "act as a hash" and aren't actually hashed, like your docs and your response imply).

I also don't understand why you point out OKTA's breach. Sure, it sucks, but just because someone else got breached doesn't mean that Faceio provides good security. This is in no way an argument.

It seems to me like this discussion is going nowhere. I have made my points, your responses didn't increase my confidence in Faceio's security and therefore I stand by my recommendation to not use it in any security context. All of this has already taken up enough of my time, so I likely will not be responding - especially if you don't properly respond to my arguments.