Hello, hello and welcome to this webinar with KuppingerCole and today, Secret Double Octopus, where we'll be talking about multifactorial authentication, how it can help against the fight against phishing, and how that is introducing a new kind of authentication. I'm very happy to be joined today as well by Horacio Zambrano, who is the Chief Marketing Officer and Cyber Strategist with Secret Double Octopus. Hi Horacio, how are you?
Good Paul, how are you? Fantastic, okay well I'm glad you're here with us. So you'll be speaking in a little while but let's kick off with the little housekeeping stuff for you. For you listening wherever you are, you don't need to mute yourselves because we've done it for you. And we've got a couple of polls coming up during the webinar and we'll look at the results during the Q&A. And there will also be a chance at the end for you to answer questions, sorry not for you to answer questions, for you to ask questions and for us to answer them.
And you can enter those questions in the panel that you'll see in your control panel on the screen. And finally we're recording this webinar so if any of your colleagues wish to see it they can and it will be available on our website very soon after today. And also the slides will be available for download. So that's that, here's the quick agenda. As I said I'm going to talk first a little bit about password, passwordless, some of the background issues. Then Horacio takes over with his piece where he'll be focusing much more on some of the capabilities that you need for MFA and passwordless.
And then as I said we have a Q&A wrap-up at the end. So before we get started on my presentation let's have a look at a poll, the first poll. Which of these technologies will have the biggest impact on identity access management in the next three years? So your options are passwordless authentication, decentralized identity, consumer identity and access management, and identity fabrics. Which of those will have the biggest impact on IAM in the next three years? So we should be voting now on what you see and once we have enough votes in we can then carry on with the presentation.
So password authentication, decentralized identity, consumer IAM, or identity fabrics. Okay so I think we've probably got enough but you can still carry on voting. But let's carry on with my part of the presentation. So to begin with this is pretty much how things are these days in IT networks, IT infrastructure, and how identities flow and how we try to manage the flow of those identities as they go from their journey from the core business infrastructure to other resources available on that. And we've identified the probably six major types of identities now in usage.
So we have traditional administrators who would have and still do have physical access to other machines, endpoints, etc. to do admin and upgrade tasks. But obviously these days identities also include people like developers, co-development, other end users, machine identities, non-human which is having an enormous impact on how we manage identities and access to resources. And of course customers as well, third parties, customers are also starting to get access to what was once considered well within the sort of boundary walls of an organization.
Now everything is much more open, everything is connected to everything else. And we use generally speaking three main tools or two main tools I should say probably for access entitlement, privilege access management, and of course identity and access management. We've been using those for many years.
These recently have been joined by another tool specifically designed for the cloud, and that is about infrastructure entitlement management, which is a slight twist on PAM and IEM in as much that it focuses less on the authentication part and more on the entitlement and how we manage that entitlement into cloud resources. So there's a lot of development going on in those areas particularly within PAM and also in CIEM. And what has driven particularly CIEM to emerge is things like platform of service, software as a service, infrastructure as a service, and also private clouds where they exist.
And finally everything is looking to access to think of file servers, workloads, containers, you name it. Everything you could possibly need to do a job and the list of resources, excuse me, the list of resources is likely to get longer as time goes on. And sort of as a kind of foundations for all of that is our traditional areas of governance and computer management, IT management, and things like zero trust, integrated risk management, data governance, privacy compliance.
And then recently we've seen endpoint detection and XDR start to emerge as a way of holistically managing everything within the sort of the network within particularly at the edge. So that's a simplified, I must say, is a simplified overview of networks and obviously the reality is probably more complicated or less complicated. So let's see what traditionally we've used for all of these things to get our identity flow. We've tended to use passwords in one way or another to give identities access to stuff that they need. And we still do. We still do.
We still use passwords overwhelmingly in our corporations, in our enterprises, in our companies. We may have added things like extra authentication, but we still tend to use as a first step to it, get into anything, a password. And so here is what I put some good advice with a question mark is that this is actually taken from the UK National Cyber Security Center website. And it's based really much on the kind of status quo that we use passwords. So it's got some things saying, always make sure that passwords are unique and they're not shared.
Make sure you review the user accounts and particularly that privilege or admin access and ensure that desktops are all patched, including third-party software, etc. Well, I mean, obviously that's all great advice. It's simple advice. The funny one is ensure privilege accounts are carefully managed and where possible use multi-factor access.
Well, that's is good advice. The problem with that is that it's not actually done. Staff don't always ensure their passwords are unique. They do share them across other systems. They share them even with each other. But they don't always make sure that they share them even with each other. Business systems are not reviewed as they should be. Privileged accounts or privileged access is not managed with a dedicated platform. And devices are not patched on kind of regular basis that they should be. So it's kind of good advice in a perfect world.
And it all comes down really to using passwords as an authentication system, which is increasingly flawed. And this is why passwords are under pressure. Traditionally, we use passwords because they are reasonably convenient. They are relatively cheap to implement. People and users understand the concept of adding a username and then a password. The problem is that using passwords like this has made them extremely vulnerable to phishing attacks more than anything else. More phishing attacks are now done through stolen passwords than anything else.
And in particular, privileged accounts are targeted by criminals looking at those access points to give them access to other parts of the network, other secret parts of the network, and important data, et cetera. So phishing is putting, and the rise of phishing and ransomware, obviously, even worse, is putting passwords under extreme pressure now to carry on being used as they are. And the cost is being outweighed also by things like breaches happening, and the company being penalized.
And the fines that are now being handed out by national privacy officers or information commission officers are pretty high. Even for the biggest organizations, we're talking about fines of millions of dollars or euros. So that kind of completely undermines any cost convenience that you may have had by using a traditional password system. So passwords are under pressure. So we need to look at perhaps some other ways of doing things. And you've probably heard of MFA, multi-factor access.
With passwords, in their purest form, although people are already adding more than one factor in different ways, but a password on its own is very weak. It's easy to find, easy to steal, and easy to copy.
And that, in fact, is the worst case, which I put in the middle there, where literally users are allowed access to networks, files, et cetera, with just a username and a password. All of that travels without any further authentication in the tier, as it were, to the service. And that bit in the middle, where all this is the plane of attack, essentially, where any of that can be taken.
As I said, we have now gotten identity access management systems that use a second authentication system, where they might use another identity provider, a separate identity provider, which does give an extra layer of security, for sure. A password is still vulnerable. And if the username and password is stolen, the authentication system doesn't necessarily know that it has been stolen. But it does give a better level of integration and trust. But what we're looking for in a more modern authentication system, or one that is more secure, is where we use a second device or another factor.
So, the device, the user uses the device to authenticate. The key travels, but a second factor also travels, and then it authenticates here, and then just gives access to the service that they want.
So, the extra device here is doing the second layer of protection authentication to the user. And that's really what we're talking about today, is sophisticated, multi-factor authentication that uses usually some kind of encryption, encrypted authentication, or even something along the lines of FIDO, to make the process of authentication more secure.
So, good authentication becomes multi-factor, it becomes based on risk. It should, at its best, be context aware, so it does understand what the user or the identity is trying to do. And that can also be called attribute level. It still remains convenient. The thing about MFA is the best types of MFA only add one extra step, normally, for the end user. And it should, if it's designed well, if it's well designed and thought out, it shouldn't be any major inconvenience. But as I said, it can be fit to the user, the usage, or the device.
So, that's still using passwords. So, what we want to get to, there's no passwords at all, if we can. It says here on this slide, password authentication is becoming new normal. And that's probably a little bit wider the mark at the moment. It's certainly becoming considered the way to go, and it could perhaps become the new normal. And the way to do it is by using biometrics or device trust based on secure elements. It can be used, you know, Windows Hello type thing, or even fingerprints. But either way, the password bit is gone forever.
So, you're moving with the trade-off before, where the convenience outweighed the security, to security is much improved. But the convenience remains the same, if not slightly better, even.
And also, there is a psychological layer of all this that people don't often talk about. But employees, users actually sometimes feel better having some extra layer, something physical, even, that they use to authenticate themselves to get into systems.
So, it's not just about making it secure at the end point, or in within the networks, but also just about making employees feel better about logging on, and they feel actually that the organization they work for cares about their security as well. So, you could argue that convenience actually is even higher. Just as a kind of, just for a slight bit of dark humor, perhaps, but not all MFA is going to work. Two layers of security or two factors is only good if it's, like I said, if it's well designed and well thought out and cannot be stolen or misused.
Now, an example, a rather alarming example of a two-factor was used in the early days of the Cold War, when US nuclear missiles were protected in a silo, and an extra pin was needed to be launched in case of attack. Now, strategic air defense commanders, perhaps not surprisingly, thought, what if people forget what the extra pin is? Then we won't be able to launch.
So, they set the launch codes to six zeros, which is kind of scary, because whilst that would have been okay in event of a live order, perhaps not so good in case of an error. So, be careful when you think about multi-factor authentication and, indeed, passwordless. Don't think that all types of MFA are going to be equal.
So, MFA is something that you really need to think carefully about, and Horacio will undoubtedly go into that a bit more. Some other things about MFA that is worth considering, although I just said that I personally think that users quite like to have an extra layer of authentication, something physical. Some may not, and they may not have their phone with them, for example, for the extra authentication bit, or they don't want to use their phone. They consider their phone their personal device. They don't want anything to work to do with it. MFA can be more expensive.
I did mention the cost factor earlier. It can work out more expensive than a traditional password system, and using tokens or biometric devices in some way is also likely to be more expensive, but you have to balance that against the reduced risk and the total cost of ownership, etc.
It can, again, can be complicated to set up and maintain, particularly maybe for some smaller users, but then there's plenty of MFA out there, which is designed for smaller businesses and is designed to be easy to use. There is MFA that is available as a service, etc.
There is, again, some MFA methods, such as MSS, which actually are vulnerable to a particular type of cellular attack, such as SIM swapping, so you have to think about that. There is also mobile push-bombing fatigue attacks, which also can be used against MFA that is based around a cellular device.
However, that's still not a reason to not think about it because the level of threat, the level of risk with passwords is much greater than that, and if you're still using passwords as part of an MFA, then don't forget they could still be used and stolen. So finally, access and management and MFA must evolve, so we need to just think about all these areas here. I'm not going to go into every one because we have run time constraints, but MFA is probably more essential than ever before.
Passwordless will, because of what has happened in the last two or three years, we're now working anywhere, there's more and more cloud, there's more machine identities which operate autonomously, we don't always know what they're doing, where they're going, etc., and customer identities, and then in the future we may see things like Metaverse or Web3, whatever it's called, or the hype for that seems to have settled down a little ever since ChatGPT came along.
Everyone's been talking about AI rather than the Metaverse, so who knows, but decentralized technologies as well, decentralized meaning stuff moving away from the central control of IT, etc., into perhaps more departmental. So that then really is my overview of MFA and the move perhaps to passwordless, but before we hand over to Horacio, let's just ask another quick poll. What are the benefits of IAM to your organization?
Is it, one, to improve security? Is it, two, to increase compliance?
Three, to save money? Four, to streamline user access management? So the main benefits you see of identity access management of any sort, don't forget IAM covers a lot of things, but what are the main benefits? Are they improved security, increased compliance, cost savings, or streamlined user access? So I'll just leave that on the screen while you vote, and hopefully Horacio is waiting for us to give us his presentation. Thank you.
Well, it's a pleasure to be here with you, and I'm glad that I can sort of share some of our thoughts here. I work, I'm the CMO and Cybermarket Strategist at Secret Double Octopus. If you don't know who we are, we've been in the market since 2015, 2016, helping companies, enterprises, specifically modernize their authentication for their workforces. So we're one of the leaders in that space, and we have a lot to say about passwordless, traditional MFA, as well as what we think is the next evolution in strong authentication, which is phishing. And so let me start by just bringing up some slides.
I'm going to go pretty brisk here because I want to show you a broad spectrum of things. First of all, we do believe that passwordless authentication will be the new normal. We've done lots of surveys, and we see that transition is going to happen over the next, at this point, four years, but we see a very high percentage of folks that are defining the move on their authentication strategy to passwordless. The first thing to realize is that passwordless is MFA. Many times people think that it's not because the word less is in there, so it's actually less secure. It's actually the opposite.
Many of the solutions in the market today, I say we're in passwordless 2.0 mode. They've really sort of gotten to a level of completeness, but what they all come with is sort of a modern mobile architecture that they take advantage of that, which includes things like using the mobile secret enclave, the biometrics on the device, the cloud notification services that these Apple and Google make available. They're FIDO2 certified. We have a FIDO2 server in our back end. We can support things like YuvaKey and many other types of FIDO2 certified keys. We'll talk about that in a second.
They're standards-based. They build on standards. It's not a rip and replace. You can use SAML, OAuth, LDAP to basically plug these type of solutions in, so it's a very important value prop, and generally, most of us have some form of adaptive MFA built in. If you've never seen passwordless authentication, I'm just going to give you a quick overview here. This is a demo of a Windows machine. It's being run over VMware. You can see that the GINA has been changed, and you can use your mobile device and the authenticator that's on the device. Here you see a geolocation.
We're going to prove that this is a push, a mobile push, and then a biometric is done on top of that, so you have two factors there, so it is multi-factor, and then you're into your desktop. This is an area that MFA traditionally has not come down to cover in an area where many mandates today require admins to have support for their endpoint. Another important differentiation is that we also support a Mac, which means heterogeneous environments. We support Linux. We support Windows servers. They're very different than a Microsoft Windows Hello.
Here you have a Mac with a FIDO key that biometric that is logging in to the endpoint, so you begin to get MFA brought all the way down, and then we're coming into a single sign-on portal where all our applications are there, and then there's a continued passwordless experience, easy password experience for the user, so this is that better security and the better user experience that passwordless authentication, passwordless MFA can bring to the table. So we, in particular, Secret Double Octopus, have been in the market for a long time. We're known as the guys who can do it all.
For us, the value of passwordless is that the user never has to remember the password, but to make that work, it's got to happen across all of the touch points that that user has during the day when they're logging into things, and so we support, I think, the broadest range of use cases in the enterprise because of the choices we made in our architecture.
We're the only vendor that has a patented rotation-based approach, and what you can see with that is that we're able to handle what's in the middle section there, a lot of the remote access to VPN, VDI, RDP, SSH, a lot of the admin use cases, and then, most importantly, the custom legacy apps, which many people believe is not doable with passwordless.
Because of this architectural approach where we're passwordless with your password directories, which many of those legacy apps are tied into, you automatically get that unified experience for the end user when they're going across all of their different resources, and this is different than Windows Hello for Business, which is a device-bound biometric. It's not going to get you that heterogeneity.
It's different than a CERT-based passwordless approach, which is also very secure but has its limitations in terms of being able to support some of these legacy apps or something like a VPN over RADIUS, a lot of difficulty in particularly doing that kind of stuff, and then FIDO2, which is really what we all live up to as part of a standard and a vision for the future of passwordless. It's a YubiKey.
That's going to depend on the platform that you use and how that's enabled, so I just wanted to give you that background if you're not aware of passwordless, but let's really talk about what we're here to talk about, which is phishing-resistant. How does MFA come into the picture for phishing? Because that's always been the domain of email, security gateways, and other types of investments that have come about in the last five years to stop this, what I think is the number one problem in security.
It's amazing that today the number of sites that have popped up from just before the pandemic to now is off the charts. This is a stat from Google, and there's a reason why this is happening.
Now, it's important to note that a few years ago, you could do a DDoS attack through a script credit. You could just buy a kit in the dark web.
Well, phishing has become sort of like that. Somebody with not too much sophistication can run a more automated approach to phishing, and it's very powerful when you combine it with other types of attacks like business email compromise, which many folks are doing, attackers, and they combine that with phishing. 90% of ransomware started with phishing, and really there's some very interesting stats around the fact that 90% of breaches are coming with a phishing involved at some point in the process.
And so this is a big sort of trend in the last few years, and I think we used to worry about zero days, but actually hackers don't need to get a lot of zero days today to get into your enterprise. What they worry about is just what they try to do is just log themselves in by finding one of these credentials that's on the dark web, the billions of credentials. So why is this problem getting worse? So let's talk about the evolution. This cat and mouse game that happens in all cybersecurity has happened here too.
You know, the attackers knew when we were using usernames and passwords that they could phish passwords. They could find leaked passwords on the dark web. There used to be even dumpster diving at one point, but this was one of the early ways that attackers try to get into the account.
Of course, over time, there were vendors like RSA. If you remember the moving, the OTP token, this was expensive, and in many cases inflexible.
Actually, one of the knocks on Yubikeys today is that they're a little bit more expensive, and you have the provisioning problem. Okay, but we did that, and then we moved, and we wanted to make that a little bit more easy to use for the user experience. So we had soft tokens and mobile authenticators, which did introduce the ability of voice, SMS, email, and emailing OTP codes.
Of course, then the attackers got smart to that as well, and they have been able to come up with things like SIM swapping, where they actually call the carrier and are able to swap the SIM, into your telephone number, and use that. Man-in-the-Middle, I'm not talking automated here. I'm talking about a fake website, which in its worst incarnation is a very clearly clumsy website that looks like something else, but it has a URL that's similar. This was more of a manual process of a man-in-the-middle attack, but some people get taken by that, and then the phish OTP as well, phishing the OTP code.
Now, the industry has moved since the days of Duo and two-factor authentication to using our mobile devices for mobile push, and the attackers realized, well, we can just keep pushing a lot of notifications and exhaust the end user, maybe at one in the morning even, to just have them, and they only have to miss one time and accept a notification that's not them. Of course, we've adapted our solutions to have things like verified push when we notice certain things.
For example, if we notice that three notifications happen in 10 minutes, we can start to do the mobile push with a code, and of course, the attacker would not have the code, or we can lock out the account if we see certain suspicious activity. The vendors have moved in that direction, but now attackers have this new thing that has emerged in the last two to three years, which is this ability to do automated man-in-the-middle attacks, and this is a numbers game.
This is how Lapsus got into Uber, and I forget the other two or three high-tech companies, big unicorns that are on the public soft market. If they can get into those companies, then they can get into anybody, and this is really a numbers game. Just to dissect it, it's still a man-in-the- middle attack where they're able to create a website that visually looks like the site that the user wants to go to, but they're in the middle of it, and they can steal a password and a username as well as a session token. We're actually going to show you what that is.
This product, EvilginX, which has come out recently, and there's a couple other kits like this. It's really quite remarkable. They can get this up and running very quickly, so what we're going to show here is GitHub, is EvilginX reproducing a GitHub.
Here, it's actually screen scraping. The attacker is screen scraping a real GitHub website that then presents it to the user, and they're going to get a URL here. You're going to see at the bottom of the screen, that's the URL that looks like a GitHub, but it's actually different, and they're going to phish the attacker, the user.
Now, the phished victim, this is what they're seeing. If you see the URL, I'm going to stop this for a second. This looks like GitHub, but it's actually the EvilginX scrape site that they're logging into, and behind this is the attacker, and so now they're putting in their password. This is the phished victim thinking they're logging in. We didn't show the code coming to the mobile device, but there is MFA here through being used, and so now they're putting in the code, and this is all being captured by the attacker.
Now, even the login looks authentic to the end user, but now the attacker over here is actually able to show that he's got the username and the password, and he's actually going to show the session cookie as well here. Now, at this point, the attacker just copies the session cookie, and now on their own endpoint, they're going to go to the real GitHub, which is here, which looks just like the one that they scraped, and now they're not even going to put in a username and password.
They're going to inject the cookie onto their endpoint, and the browser itself is going to believe that this is the original user into GitHub, and then they're going to be able to log in to GitHub.
Now, they refresh the screen, and now they've been phished, and now they're in as the user, so this is a big development in the phishing world, and the reality is a traditional MFA cannot stop an automated man-in-the-middle attack, so this is the big change that's happened in the last two or three years, and government organization standards bodies have realized this, and in early 2022, President Biden's mandate to all of the government agencies in the U.S.
and the critical infrastructure was that they need to move to zero-trust architecture, and phishing-resistant MFA was called out explicitly. NIST has not necessarily called out phishing-resistant MFA as much. They have 800-63 as a sort of a guidance rule, and in that, they talk about a form of resistance for impersonation, for replay attacks, and man-in-the-middle attacks.
CISA, I will show in a second, has definitely sort of talked about phishing-resistant MFA, and NIST itself in Europe has also put out some MFA mandates and discussion about this. CISA in particular has put out this table of what is the most lax type of MFA, which is SMS and voice, which at least in America and the U.S. government has said that this is not a good way to do MFA because of SIM swapping and other types of attacks, to an application-based mobile sort of soft token.
Then you go up to the next stack, which is app-based authentication using one-time password codes and token-based OTP, and then lastly, phishing-resistant being the strongest form, and they call out two ways of doing it, FIDO MFA using FIDO WebAuthn and PKI-based certificate-based. Now, they're actually, this is where we have innovated, and SDO, which is doing a rotation-based approach, supports phishing-resistant through a desktop-to-app pinning mobile push, so you don't have to pay the price of a certificate-based approach.
So what we offer across to solve this problem is, one, for the push bombing, we offer adaptive passwordless MFA, and these are things like a verified push where you have to bring in the numbers, you obviously use biometrics on the phone, which the attacker wouldn't have, and geolocation. So we're trying to stop push bombing and account takeover attacks this way.
Now, this is not phishing-resistant, but it is a stronger form of strong authentication, if you will. The two other ways we do get into phishing-resistance is through the support of FIDO-2 tokens and through what we call an MFA mobile push, phishing-resistant mobile push, and this is really innovative and different, I think, in the market. Let me talk about each of those very quickly. So FIDO has defined a standard, which in these Yuba keys and in these security keys, they're taking advantage of a TPM to store a private key.
So they have defined a public key in cryptography where there's a public key that is held at a relying party, sort of a server in the cloud or on the back end, and then the key that you hold has your private key.
So when you log into something, there is a binding as to where you're actually going, whether it be an SSO portal, whether it be a web app, there's a binding to that that is authentically the domain you need to be at, and then there's a challenge that this server, which is talking to that binded sort of domain, is sending to the endpoint or to your security key and that only that key can sign. So a person that's attacking doesn't have the key physically, so they won't be able to get in a FIDO MFA authentication, they won't be able to get into the site.
And what we do, I'm sorry that the words have been sort of changed here with the accents and all. This is English, actually, but it looks like Czechoslovakian or something, or somewhat Slavic language. But here we have the endpoint, now we have a desktop agent on the endpoint to be able to do our MFA on the desktop, and we can support the FIDO token because we become the IDP. Double octopus becomes the IDP, whether we're working with Octa, Ping, there's sort of a delegated IDP function that can be set up.
We have our own single sign-on portal, but typically in an enterprise, applications are going to be corralled in the single sign-on portal and accessed through that. Now this is very good, FIDO is very good for web applications, but what we're able to do is extend that web auth in and that security of a FIDO MFA to the other resources that we talked about before, like VPN, VDI, and even custom legacy apps. So we are a bridge, secret double octopus, because of our architecture can be a bridge for these type of use cases.
Now when we do it from our mobile authenticator, what we're doing is actually creating a TPM, we're actually creating sort of a secret enclave in our desktop agent to hold a private key and a certificate. And so we're able to establish what we call an origin binding because we're using our single sign-on portal or Octa, that's the domain that you're trying to register into to get access to your applications.
And so we did create a channel binding because the endpoint itself has to have this private key and similar to the FIDO key, we're actually able to issue a challenge and get through the challenge from our desktop endpoint. I'm going to show you how that works.
Now, what's interesting here is that this is sort of, we can actually do this and bring that to all of these other resources as well. We can bridge over to the VPN, to the VDI with this phishing resistant MFA that we can implement into that broad use case coverage. And so let me show you actually, well, let's look at very quickly how this affects the automated man in the middle phishing attack that we showed. So effectively, the attacker does not have the pinned certificate that's on the desktop, or they don't have it on the FIDO key.
So they will not be able to get into the GitHub or whatever solution they're trying to get into because they don't have that channel binding. And the actual fake site does not have the backend FIDO server that is actually or that's actually verifying with a public key that's making the challenge to the endpoint. So this breaks as well, the ability for them to steal a session cookie or the username and password. And so I'm going to show you very quickly what we can do here. So here we're going to enforce, when you see here, enforce launch from the agent, that's our desktop agent.
So this is going to create the pinning that we need for this phishing resistance. So we're going to enforce that. And what you're going to see from the admin console, we're going to publish that out to our enterprise. And then you're going to see the attacker here try to, well, here first is the user just getting in with a FIDO key. And some of the FIDO keys use a pin, so he's logging in.
But first, we're going to go to the website where what the attacker would try to do is go to this website and just type it in, whether it be GitHub or what have you. But they're going to get the login is disabled because you need to use your desktop agent. And if you're not using the endpoint where the octopus agent lives, then you're not able to access this. And in this case, it's going to be your secret sign on portal. So you're not able to get to portal, which has all of your apps to get out to the end, all of your services like VPN.
So here, we're going to show a different use case. And I think I just where we're going to show the opposite, where the user goes down to the sys tray down at the bottom. And this is our agent. And they're saying launch the single sign on portal.
So here, we're pinning the origin, which is the domain we're really going for, which is our single sign on portal, and the desktop, which has a certificate stored in sort of an enclave there securely. And so now we're able to get access to the real site. So this means this is because of this desktop to app pinning, the attacker is not going to be able to do this and be in the middle.
So, you know, we pride ourselves in the number of use cases that we can cover across desktop applications, including legacy applications and VPN, and privileged access for admins. And what we do is we can provide all these methods mobile push Fido to we even support smart cards now. And then we have the traditional MFA to get people started, and then slowly get people to passwordless. And now we were able to introduce with this pinning this phishing resistant ability to get to a lot of these use cases. So really what we we think that we're unique in the market.
We've been out there for, you know, since 2016. We have a lot of customers now in the hundreds, and we're industry proven, we've won awards for technical death. We think that this approach is easier for companies to deploy. It's different than a certificate based approach. But as you can see, we actually can create some of the same levels of strength around phishing resistance. And then because we work on your password directories, you know, everything that you've got set up, we're really rotating the password, we're able to onboard users very quickly, our cloud based back end.
We've shown we have a video on our website where we show that you can get up and running in one hour. This is remarkable. You can also run it on premise if you want to do that. So this is some of the value prop, and I'm happy to take questions or emails at any time in the future. Thank you. Thank you for that excellent presentation. I'm just going to relaunch my deck, and then we'll have a look at some of the questions and also the poll answers that we have. So you should now see this on your screen, the agenda, etc. So so now I've got to find the the questions that are also on another window.
And I don't know if I can do that without. Let's just see what happens here. So I apologize, we're using a new platform. It's the first time we've used it live. So please bear with us a little bit. Okay. I'm going to leave you on screen for a minute there, Horatio, I hope you don't mind. Because it's the only way I can read these questions. But first of all, let's look at the poll results, which were the first one, which of these technologies will have the biggest impact on IAM in the next three years?
Well, you'll be very happy to see that passwordless authentication 50% was the top answer, followed by decentralized consumer IAM. And then again, let's have a look at the benefits of IAM.
And well, I guess not surprisingly, improved security was the top answer. Interesting that no one really cared about cost saving or even increasing compliance. But the two kind of fundamental issues security and user access management were certainly the highest. So there you go. We do have some questions, Horatio. So I don't know if you can see them, but I'll read them out anyway. And this is a, does your solution support Windows core server operating systems? So that's a technical question for you.
I need more information on the core server operating systems that they're, what they're referring to there. But we support obviously Windows 10, we actually go back to Windows 7 as well, way back. But yeah.
Well, if that person could perhaps elaborate in while we're still on air, or if they could follow up with an email. Well, so we also support Windows servers.
Yes, we do support Windows servers, Linux, Linux through PAM module on that. You know, RDP, SSH, passwordless RDP, SSH, passwordless sudo. We have support for all of those sort of admin things if that's what they're referring to. Yeah. Okay.
Well, hopefully that answered that question. Okay. This is interesting. What is differentiating the SDO password solution from Windows Hello for Business? In other words, should it replace, augment, or complement Windows Hello? I think fundamentally we are made for a heterogeneous enterprise. And we find that increasingly executives, different vendors have, are bringing in Mac devices, they may be using Linux servers as well.
That's not something you're going to get from Microsoft at that type of coverage, at least not to the degree of universality and sort of feature parity that we're doing across all those resources. The legacy applications is another one. Because we can bring our architecture of rotation to those legacy apps that are already tied to a directory. You don't have to change them. You don't have to PKI enable them, don't have to SAML enable them. But we can also do it with legacy applications that just have their own database that are not tied to directory.
So that is a very innovative approach for us that I don't think that Microsoft has potentially focused on that. So as specialists for passwordless, we really spent a lot of time with big corporations that have our largest customer has 150,000 employees logging in every day, mission critical with our solution. That took us a long time to build all these customized features and ability to deal with that. So if you're an all Microsoft shop, you have an E5 license and you got MFA out of the box, we often see people try that. They just go that direction.
And if they use Windows Hello, sometimes their users are docking the machine, they're closing it. So Windows Hello doesn't work there. So the user has to still type a password. There's really a password under the covers in Windows Hello for Business on the endpoint. We can actually, we're rotating that password. So we remove that risk. We remove the need for the user to ever remember it. And so in Windows Hello for Business, sometimes you cold reboot the machine, you still have to remember it, but you're not typing it as often.
So it's actually worse because you're probably going to put it on a yellow post-it in that case. So I think that there are nuances here that would require a longer discussion on Microsoft. But we have seen people go the direction of Microsoft and come back to us nine months later and then are able to do what they want to do with us. So very technical nuanced differentiation here. Okay.
Well, we can, any of you can follow up with more detailed questions and we can make sure that Horatio sees them. I guess that's okay with you Horatio, but so that if you want to go into a deeper dive with you on how it might suit their particular infrastructure or setup. I don't know if we kind of answered this already, but it says how does Secret Double Octave C pass keys solving authentication issues? You mentioned also certificates as in it's better than certificates as well. So interested in your view on that.
So we wrote a blog, there's a blog on our website that we wrote when the Google, Apple and Microsoft announcement came out for pass keys. And we didn't have a lot of information on the enterprise strategy there. It seemed to be more consumery. And when I read it, really trying to read into it, we didn't see the articulation of a strategy for pass, Fido pass keys from those big vendors for the enterprise.
All of the different use cases that we have to support, like I said, six years of working with these big customers and lots of feature requests for this and networks and VPN over radius and LDAP and different types of scenarios. We didn't see that the pass key concept had that articulated. I do believe that Fido is, we don't believe Fido is completely ready for the enterprise. We do believe Fido is the passwordless future. I actually, what I showed you on our slides is our ability to bridge, to bridge, to getting to legacy apps.
You can't take a Fido pass key or a Fido key today and instantly make it work with a legacy application and potentially some types of VPNs configurations. We can actually take the Fido, accept it as having our server and bridge over to those other resources. And so we see ourselves as a bridge to a Fido future. We don't think all the elements are there. The concept of pass keys is nice. It actually, for us, we don't like the idea of taking, we're very heavy security oriented companies.
We don't like the idea of securities being, certificates being portable, because you do lose security with that. It's not as secure as a YubiKey, as a security key. Pass keys sacrifice some security for the convenience of being able to have portability. And I think that now Fido is starting to put out white papers on their strategy and the enterprise. So it is developing. We have some of our competitors who are using the word pass keys, but it's not exactly what was announced. And so we are actually looking at it as well.
I think pass key for us means higher convenience across portability and what are the trade-offs we'll make to be able to support security. As far as certificates, I'm not saying that our approach is more secure. Certificates are very secure. I'm saying that you can still get the fundamental goal of full passwordless, which is the user never has to remember their password. And with our approach, you can get it across more use cases that they're going to touch throughout the day.
And you're going to be able to deploy it faster because all your password resets and things that you already have built, syncing between directories, you don't have to change that because we're working fundamentally with a password directory. When you have a certificate-based approach, you have to think about how the password gets deprecated. And you now have to possibly stand up a whole new infrastructure for your endpoint. It's around PK. There's just more work involved around it. And we think it's more seamless to go our direction, our way we did it. Right. Right. Yeah.
And actually, for those interested, the FIDO Alliance has a very good website full of blogs and technical data as well, which keeps you abreast of developments in FIDO. So let's just end with the classic question, which is, will we ever get rid of passwords altogether?
I mean, if you're saying 100%, I don't think so. I mean, I think there's always going to be some straggler out there. But I think the majority of the market will move to passwordless in some form or other. Because there's so much confusion between biometrics on the device and things, it may be difficult to get everybody off of a real password. And you can see supply chain attacks. You've got the long tail of small and medium businesses that are going to take a while to get there. And so the threat of password infiltration will be there for a long time, maybe forever. Yeah. I reckon so.
Some people just like passwords. So what can we do? So Mauricio, it's been a pleasure having you on today. And as I said, these slides, someone asked the question, are the slides available?
Yes, they are. They will be available from Kubinka-Cole website under the webinar section. Give it a day or two for them to be uploaded. But you'll also be able to see the recording of this along with the slides. If you do have any extra questions, then please feel free to email Kubinka-Cole. And we shall do our best to answer them. And I can also forward anything on to Horacio as well. So with that, thank you so much for listening. Thank you for being with us.
Thank you also, especially to Secret Double Octopus for supporting us today, and especially to Horacio for that excellent overview of passwordless and its potential. So with that, I will say, very good day. Thank you. Bye-bye.