[HN Gopher] Launch HN: Xix.ai (YC W17) - Securely authenticate i...
___________________________________________________________________
Launch HN: Xix.ai (YC W17) - Securely authenticate in web apps by
face
Hi HN, I'm Emil, here with our team at XIX.ai
(https://getxix.com/). We are building "Entry" - a biometric
identity provider that enables secure authentication in web apps by
face on desktops using web cameras. It supports SAML 2.0, OIDC
Connect, and OAuth 2.0 standards and can be easily integrated into
existing app or infrastructure. Users can securely authenticate in
web apps by face, using regular web cameras without compromising
privacy and security. Entry helps organizations prevent phishing,
insider threats, and account takeovers by adding Entry as a
biometric factor to their workforce SSO. Companies that employ many
contractors or vendors to access sensitive information can prevent
fraud by verifying biometric identity during authentication.
Developers can use Entry to verify their customers (password
resets), strong-authenticate users during high-value transactions
(pushing code in master; deleting data, etc.), or streamline the
login experience. (documentation and self-serve are coming soon.
Please reach out if you'd like to try it now) We came to the world
of identity and access management somewhat unexpectedly. In the
early days, we tested different product ideas and frequently
pivoted while focusing on problems that could be solved with our
core expertise, computer vision. During our trial and error
period, we were lucky enough to work with the team at DeliverFund,
a non-profit organization fighting the problem of human trafficking
and child exploitation. More often than not, the only clue an
analyst has is a photograph of a missing juvenile. With that photo,
they need to search through the web to find any ad or other
indications that may lead to the child. To locate a missing child
or a victim of human trafficking, they had to manually scroll
through thousands of online ads to find a potential match. To
solve this, we built a set of scrapers that capture online ads,
indexes them, and makes them searchable. We took all images and ran
them through face recognition and object detection models. This
enabled analysts to drag and drop a child's photo and see if they
are being trafficked from ads online. With internal expertise, we
were able to build the tool back in 2018. And this experience got
us thinking: a malicious actor will make a wide-scale surveillance
system with enough resources. It's not a question of "if," rather
"when." While brainstorming a potential solution, we've realized
that, fundamentally, this is an information asymmetry problem. A
feasible solution must be market-based, user-privacy-centered, and
optimized for perfect information. Such a solution must satisfy a
few criteria: a) has to use a face as a biometric modality b) must
be valuable enough for a large number of people to use it c)
biometrics must be securely stored and 100% controlled and managed
by the end-user d) And it has to deliver an order of magnitude
improvement in overall security and usability in comparison to
existing solutions. This brings us to the world of identity and
access management. Passwords can be easily compromised. Additional
factor authentication is either convenient but phishable
(SMS/Voice/Backup Codes/TOTP/Mobile Push) or phishing-resistant,
but inconvenient, expensive, and not widely adopted (FIDO-keys,
Webauthn). Biometrics is a perfect solution but by no means a new
idea. After all, we are using it already on our mobile phones
(fingerprints, FaceID), specific Microsoft devices with Windows
Hello, and other desktop devices with fingerprint sensors.
However, four key challenges prevented biometrics from being widely
adopted: a) the need for a specialized sensor - depth perception
for cameras or fingerprint sensors b) 2D webcams are easy to spoof
with replay attacks, printed attacks, and mask attacks. c)
Scalability, reliability, and cost-effectiveness. Products with ML
at the core are notoriously computationally expensive and result in
low margins. Accuracy also decays with data growth (more faces =
higher chance of false positives), regressing the security over
time. d) Privacy. How to avoid having a copy of my face on every
website/SSO I login? We've spent the last two years solving those
challenges, and we're happy to present to you Entry. It works with
a regular desktop webcam and doesn't require installing additional
software. We've developed several anti-spoofing layers to make sure
the system is secure. Entry is compliant with CCPA/GDPR and
supports users from the state of Illinois ( arguably, the strictest
biometric legislation in the USA) Please give it a try
https://getxix.com/. We've rolled out a public Okta instance with
Entry set up as a factor to showcase it. We support Okta SSO out of
the gate. Others (or working with OpenID Connect) require talking
to support. If you'd like to add Entry into your SSO, use it for
your customers, or secure high-value transactions, let us know.
Documentation is coming soon, but we can help now.
Author : emilxix
Score : 37 points
Date : 2021-02-28 15:38 UTC (7 hours ago)
| giovannibonetti wrote:
| Do you plan on using your face recognition tech with documents as
| well? I'm currently working in a Brazilian Fintech and we pay a
| third party for reading document IDs checking if the user face
| matches, and ensuring the user is really there alive in front of
| the camera.
|
| The third party service we have now is well below expectations,
| so we would be glad to try out something new.
| emilxix wrote:
| Absolutely, that's on the product map. KYC/AML and document
| verification use cases are super exciting but require some
| thoughtfulness around regulations. Sometimes it is easier to
| solve a hard technical problem than to navigate compliance
| requirements.
| symisc_devel wrote:
| Checkout the PixLab API[1] which offer KYC document
| verification (IDs & Passports) and face recognition via the
| same WEB API.
|
| 1: https://dev.to/unqlite_db/implement-a-minimalistic-kyc-
| form-....
| iujjkfjdkkdkf wrote:
| Have you thought about what kind of assurances users / buyers are
| looking for about robustness to attacks or false positives, but
| also about working correctly under normal variability (a
| mentioned by others)? And how to best communicate those
| assurances?
| emilxix wrote:
| Communicating assurance is challenging. Finding a balance
| between "FAR/FMR/FNMR metrics" and "it's safe to use" is an
| art. Apple's faceID. for example, claims "1:1,000,000 chance a
| random person can unlock an iPhone", which, I guess, is a good
| enough proxy to communicate assurance for the intended
| audience. Answering the question, yes we thought about it, but
| still a work in progress.
| iujjkfjdkkdkf wrote:
| Thanks for the answer. What I should have asked first is, do
| you think this is something that's important to your users,
| or are they happy to accept that there is research and
| engineering behind it that has concluded it is reliable and
| safe?
|
| I'm asking because I've been in a similar situation
| (different area of computer vision) where nontechnical
| stakeholders are looking for assurances that the model is not
| going to fail under essentially unknown conditions. And same
| as you, we had some ideas, but it's hard to validate what
| best speaks to people, so was curious to hear if you had
| looked at it. Thanks!
| emilxix wrote:
| Got it. Let me share with you our experience, and please
| take it with a grain of salt.
|
| Early on, we've conducted a handful of end-user interviews
| - knowledge workers, various industries, fluent with
| computers. We conducted a series of hour-long video calls,
| recorded them with permission to re-watch them later, and
| asked the questions like - how do you think about privacy?
| How do you think about the performance of faceID or
| similar? How do you think about biometrics and privacy?
| Will you be open to try a solution that uses your
| biometrics from an unknown vendor? Etc.
|
| The result, somewhat surprisingly, boiled down to a few
| bullet points: 1. Performance- "If it works and I can log
| in, that's enough assurance." 2. Privacy and data - "Have
| an FAQ section or show in me onboarding that you don't sell
| my data for surveillance - that's good for me."
|
| We've been prepared to answer the "SOC 2 Type2 -style"
| question regarding performance and data privacy, but no one
| really cared. What users did care about is "can I add this
| app to my account?" and other feature requests.
| iujjkfjdkkdkf wrote:
| Thanks, that's very interesting to hear.
|
| I wonder if / how the concerns will change for different
| use cases, e.g KYC.
|
| It may also be a question of educating users about the
| things they should care about.
| trojstan wrote:
| It would be amazing if this could become the future, but as
| someone working in the adversarial robustness space I find it
| difficult to believe a system like this wouldn't be susceptible
| to adversarial patching...especially with whitebox access. It's
| been shown by Nicolas Carlini that nearly all adversarial
| defenses can be broken or are inherently flawed.
|
| Very curious to see what makes this anti-spoofing algo different,
| will read the paper with interest.
| emilxix wrote:
| right, adversarial attacks are tricky, we wrote about it a
| while ago - https://blog.ycombinator.com/how-adversarial-
| attacks-work/
|
| In reality, the production-grade security comes from a compound
| effect of three components: face-recognition, antispoofing for
| face recognition, and traditional controls of industry-standard
| protocols like SAML 2.0, OIDC, etc. Taking one of three out of
| the equation renders security nonexistent.
| JohnOffenhartz wrote:
| Also worth mentioning that since we're cloud-based, we can
| shore up our threat assessment models to include browser
| fingerprinting, device details, IP address history, what
| network the user is on, etc. to better detect
| threats/spoofing.
| mooreds wrote:
| Cool idea and good on ya for your work with DeliverFund.
|
| How is this better/different than the face identification built
| into the major platform providers accessible via WebAuthN? My
| understanding was that WebAuthN was supported by the latest
| version of major browsers: https://caniuse.com/webauthn
| emilxix wrote:
| thank you. You are right, Webauthn taps into SDKs of platforms
| like iOS, Windows Hello, google's version of android. They use
| infra-red depth perception sensors to create a mesh of the
| user's face as ID and store it on the device's secure enclave.
| It can only be accessed and used on that device. For that
| reason, Apple users have to set up fingerprints separately on
| iPhones and Macs. The same will be for FaceIDs on the new-gen
| of Macs - users will be setting it up separately on different
| devices. We instead store biometrics in the cloud so it is not
| tied to a specific device.
| mooreds wrote:
| Thanks, that makes the differentiation very clear.
| nathancahill wrote:
| > in the cloud in the secure enclave
|
| Choose one.
| emilxix wrote:
| good catch, I've fat fingered it while editing the comment
| ashneo76 wrote:
| The thing with yubikeys is that, I can change them. I can't
| change my face or fingerprints. Use that for authentication
| reduces control over privacy and enables tracking across the web.
|
| Was there an audit but independent privacy focused organization
| done of your claims? Till then any privacy claims are just
| claims. New day, new privacy friendly face recognition that will
| website big corporations to do tracking in the name of "kyc" and
| security
| emilxix wrote:
| Entry was designed to protect end-user privacy against
| malicious actions in the first place. Not just because we want
| to "do good", but also because it is commercially viable: End-
| users get full control of their data forever free, while
| organizations deploy Entry to solve tactical issues like fraud,
| security, and phishing prevention. But, I guess, without an
| independent audit by "the big four" or alike, these are just my
| words.
| cletus wrote:
| Some general thoughts:
|
| First, let me say that on mobile devices, I literally loathe Face
| ID. There are lots of reasons for this:
|
| - Fingerprints are just more convenient. Apple, for example,
| argued the false positive rate way too high. For me, as a user,
| I'm more concerned about the false negative rate. I think Apple
| just wanted more screen real estate. They could've easily put the
| sensor on the back (eg like the Samsung Galaxy S8).
|
| - I have poor vision. I have to look at my phone close, same with
| my computer. And no this isn't an issue of better glasses or
| surgery. This caused Face ID to fail because I'm not in the
| expected frame. So I have to hold my device further away and try
| again. This is incredibly annoying;
|
| - Touch ID has a much lower false positive rate on whether to
| initiate a check. That's because you've pressed the button. Face
| ID has to guess and it guesses wrong (a lot);
|
| - I can't speak for other manufacturers but Apple at least puts
| in arbitrary security controls like N failures mean having to use
| my passcode many times a day whereas with Touch ID it's actually
| super rare;
|
| - Masks!
|
| - Touch ID isn't dependent on sufficient lighting
|
| More context: prior to Touch ID I didn't use a passcode on my
| phone at all. It was simply too annoying. Face ID, for me, is too
| close to having to use a passcode too often.
|
| I mention this as context for why I personally think facial
| recognition as an authentication tech is a terrible user
| experience in many, many cases.
|
| Desktop is probably a little better because issues like your face
| not being in frame are going to be less of an issue. In my case I
| still have to sit close to the screen but my face is still within
| frame.
|
| Phone manufacturers make this approach more resistant to spoofing
| by using other sensors. You say you've spent effort to avoid
| spoofing and hopefully that's true. I would be concerned that
| there's only so much you can do with a single vision camera and
| no other sensors.
|
| Phones (and tablets) also have the advantage in they have a
| single manufacturer. Desktops are still put together with
| independent peripherals. That's... less secure.
|
| Lastly, it's not a given that someone using a desktop or a laptop
| has a camera that's facing them.
| emilxix wrote:
| thank you for sharing your thoughts.
|
| -> Fingerprints are just more convenient. Apple, for example,
| argued the false positive rate way too high. For me, as a user,
| I'm more concerned about the false-negative rate. I think Apple
| just wanted more screen real estate. They could've easily put
| the sensor on the back (eg like the Samsung Galaxy S8).
|
| I agree, a matter of fact fingerprint sensor on the back of a
| phone is arguably the most efficient way to unlock a phone.
| With desktops, it varies quite significantly.
|
| -> - Masks!
|
| for what its worth, one user told us that they have
| successfully logged in while having a green mint facial care
| mask on..:)
|
| -//-
|
| By no means Entry is the best tool out there, nor we claim it
| to be so. Here are a few known flaws:
|
| - if someone has two or three monitors and it is unclear where
| the camera is, it requires some time to get used to, which may
| be annoying - to your point, Entry will not work in a pitch-
| black room - Entry is by no means "fingerprints-fast": as a
| factor, Entry competes with the time it takes to reach a phone
| and click on push notification. For example, mean time to
| verify using Okta Verify (default mfa solution for okta sso) is
| ~21 seconds. For Entry it's 30 seconds. We still need to work
| on that (although our users still choose Entry over Verify, we
| ask to have both factors set up :) )
| anandchowdhary wrote:
| I love the idea, I had a similar one two years ago
| (https://github.com/AnandChowdhary/notes/blob/main/notes/2018...)
| to use "face unlock" but as an MFA method.
|
| The one problem I had was that face detection using the webcam is
| not be accurate, e.g., it can be easily fooled using a printed
| photo of the person or changing the webcam input to use a static
| photo. With WebAuthn, however, this is not possible because it
| connects to the device's native authentication. On macOS, for
| example, it's much harder to spoof Touch ID.
|
| How would you go about preventing such problems? Isn't it better
| to provide an Auth0-style SDK to use WebAuthn with SSO, or do you
| think using this cloud based image recognition system is as
| foolproof as the native options?
| emilxix wrote:
| That's right, successfully preventing spoofing attacks using 2D
| input is an extremely hard problem to solve. We've spent two
| years working on it. We published a high-level overview here -
| https://getxix.com/learn and plan to publish a deep-dive
| overview of the approach in the coming weeks.
|
| For SSO, Entry can be added as SAML 2.0 Factor today. I agree
| if we would not have solved the spoofing problem, taking the
| Auth0-style route for native platforms is the way to go.
| wgjordan wrote:
| Relevant quote from the linked overview:
|
| > Entry addresses the spoofing issue from 2D input by using
| an anti-spoofing algorithm that processes a sequence of
| images obtained from a single camera to build an accurate 3d
| face reconstruction based on facial key points. Additionally,
| it estimates the pixel distribution of the input image to
| detect attacks. Aggregation of both methods achieves high
| accuracy for detecting attacks on face recognition systems.
| emilxix wrote:
| thanks for posting it here. It is still too high-level.
| We'd be publishing in-depth details soon.
| carlosdp wrote:
| What stops an attacker from spoofing the webcam with a
| looping video of the subject staring at a camera instead of a
| still image or holding up a picture?
| emilxix wrote:
| Several layers of anti-spoofing.
|
| They detect mask-attacks, replay attacks (put the phone
| with video into the camera; highjack a webcam input and
| send a pre-recorded video faking to be real-time from zoom
| for example), and, of course, still images.
|
| Give it a try!
| pmiller2 wrote:
| Wouldn't you still be vulnerable to attack via a 3D
| printed or resin cast face (possibly suitably painted)?
| qbasic_forever wrote:
| Or just tape a print out to a balloon.
| ignoramous wrote:
| > _I love the idea, I had a similar one two years ago (https://
| github.com/AnandChowdhary/notes/blob/main/notes/2018...) to use
| "face unlock" but as an MFA method._
|
| btw, https://gazepass.com does this as well.
| ma20102019 wrote:
| On the price; $4.5 per user, for a store with 100 customers it
| will be $450 per month? Am I correct? and for 1000 it is $3500
| per month?
| emilxix wrote:
| Yes, you are right. To be clear, the pricing on the website is
| for the workforce identity (Entry as a factor to a Single Sign-
| on solution). If you are thinking about customer identity, we
| don't have pricing yet. Most likely, it will be volume-based.
| It would be great to brainstorm with you and come up with
| something that makes sense!
___________________________________________________________________
(page generated 2021-02-28 23:00 UTC)