I think, you know, we've all been here for the last four days, and I'm only allowed to speak for 10 minutes here. So I'll try to make this one a bit more casual. And I'll share a bit of a reflection with you first before we get into this topic here. We are a vendor of passive authentication. So it is funny, when I'm at the booth and whenever I introduce myself saying hi, my name is Prem Cherklevich, I'm the CEO of Relock, we are the passive authentication company, a lot of you, I can see, you know, with your mouth, you say, oh, it's great to meet you.
But at the same time, what I see in your eyes is a bit of a defiance, passive authentication, that I either have it under a different name, or I don't need it. And I get it. To be honest, I get it very well. Because for the most part, most of you are doing the right thing right now with your authentication. And for the most part, most of you have already a bunch of different software tools that allow you to put phishing-resistant secure authentication options at the reach of your users. The problem is, they don't reach, right? They don't do it.
And we all know here that the bar for what can be considered secure authentication, secure access, has been rising tremendously over the last years. And you've been probably on the road to the password list, to roll out passkey, so on and so forth. But then most of you realized right now that the group of options that you have to make access really secure is very, very narrow. Right? It's mostly like hardware keys and the passkey is enforced as the only method of authentication.
Now, the problem is that you've been probably doing this, but people are not there yet, right? So the main barriers for you to get there is actually not within your control. It is on your user's side, right? If you think about these use cases where you may want to protect the access to your applications and the problems that you face, they are not on the technology side right now, or mostly they're not. It's typically friction, time, cost, and limited visibility. And I love the fact that I'm following you, Mikhail, because your presentation is a perfect intro for what I'm about to say here.
Because you are here in this corner, right? Where you know that federation is a great thing. And customers very often don't need to be convinced. Very often they come, right? And they ask for federation. Can we come in with our login? Can we come in with our own SSO? We would prefer to do that. It's convenient. It makes sense, right? For you as a business, it means, yes, I'm within their perimeter now. I'm making the UX much more friendly to my customer. That's great, right? But there's a flip side of it. They are in my perimeter as well, right?
And I have very limited visibility over their authentication flow. So if the benefit is higher than the risk, you may say, let's do it. Let's trust whatever SSO they are using right now. But for some institutions, like banks, for instance, they don't want to do that. For some other companies that we have seen, what they end up doing is they end up provisioning these customers within their own IAM with the cost that it entails. Right? So what we offer, and why we call it passive authentication, is we offer for you a way to solve this problem today. Or to solve a large part of this problem today.
What we offer is a small piece of software that for all of these use cases, where you're thinking, I would love for my users to be only using hardware keys, but for the life of me, can I get them there? You can grab Relook, put it in the back of your application, and make sure that their access is resistant to credential theft, resistant to phishing, resistant to session hijacking, including advanced stuff like adversary in the middle.
And do it, this is the most important thing, if you get one thing out of this session, do it in a matter of a couple of days, sometimes one day. Why? Because it's invisible to the user.
Now, what we do, I will not go into the whole marketing narrative around this. What we do to be very, very direct is we push into your user's browser a sort of lightweight device identity. It's not fingerprinting, it's not security signals, it's not behavioral or contextual signals. It's an actual cryptographic authentication factor that is pushed into the browser that you verify in the background at every single request that they make. And you make sure this way that they are coming from a device that you trust. And I'll show you what it looks like here. That's essentially Relook service.
There's three components to it that you need to be aware of in this brief time that we have. One component here is the Relook service. This is what handles the cryptographic part of things. And this is right now, that's just a Docker container. So you can self-host that, you can have it on-prem, you can use our own in the cloud, or your own in the cloud, if you prefer. Then there's your application here, and the active authentication flow that we don't touch. Use whatever you want, right? Use your SSO here.
This actually can be your SSO, but it also can be any other application, because it works at different levels of abstraction. And there's the browser component that is invisible to the user. That's just a JavaScript that is served by the application. Right? And what we do is very simple. Every time the user comes back and every request that they make, Relook service will renew, re-lock the key that we have there, and send a cryptographic challenge to the browser and say, hey, prove to me that you can do this in the same way, because I know that you have the same version of the key.
And prove to me that you now have a correct version of this key. The response comes back saying, hey, yes, here's my proof, I've done it. And then we share a security signal with the application and we say, keep trusting.
Or, if something is wrong, we say, do not trust. And this, to summarize quickly, this would prevent especially three types of attacks. If someone comes with a stolen password, but they don't have the passive authentication keys in the browser, we say, don't trust. Lock them off. Right? If someone bypasses the entire MFA flow, because they come with a stolen session cookie, but they don't have the passive authentication keys, we say, do not trust. Right?
And then even if there's an adversary in the middle type attack, which is right now often the case in the case of phishing, even if there's a fully functional browser that can modify the entire flow of information and can, for example, make your users log in with their password instead of their pass key, they do not have access to our passive authentication keys, because these are origin model. So we will also say, do not trust.
Moreover, interestingly, we are also a CAPE-enabled partner. There's an ecosystem of about 30 companies right now, including Okta, including Thales, Signal, so on and so forth, that accept CAPE events, which is basically a fancy way to say a specific type of JSON to say this user has been compromised, lock them off.
So we can, when we see that happen, we can propagate that across this network of partners. Now, an interesting implication, just to leave you with something a bit more in depth, is that given that we are using only one time transient keys and the key is different for each request, what happens is, even if we are compromised ourselves and the attacker grabs everything from the browser, for example, with the targeted malware, right, they only have as long to access your application as long as the user is inactive.
Because the first click from the user will change the key on the application side, and the application will say not only, hey, this user has been compromised, for sure, I know it, but also I know exactly when, how many requests ago, and what happened in the meantime in the application. Now, this allows us to cover a broad range of different use cases, such as, for example, federating with partners, right, and verifying them in the background, allowing them to come in with whatever they want.
Use cases like unruly colleagues, who you've been convincing, you know, for the last six months or a year to transition to pass keys, but they don't, right, in the meantime, verify them with us in the background. And, of course, SIAM, any kind of customer facing applications where you want your users to still be able to log in pretty flexibly, but you want to be able to also verify their security in the background. Because at the end of the day, we all know here that what we are protecting is not the security of the user, it's the security of our applications, typically.
I'll pause here, feel free to visit us, we are on the second floor next to the candy bar. We are a company called Raising Star, been named just this month, so feel free to grab a report and come up and chat for any questions. Thank you.
