Welcome to our call webinar fixing the way the world locks in this webinar is supported by hyper and speakers. Today are with vice president continental Europe at hyper and me Martin Ko, I'm principal Analyst Analyst at Ko Analyst. Before we dive into the topic of today's webinar, some quick hints on upcoming computer call events and also on the housekeeping. And then we'll directly start with webinar. So we have a couple of Casey live. These are purely online event, virtually events coming up on early June around cybersecurity fabric, the other early July about the future of anti access management. And then in November, we'll have our next hybrid event in Berlin, which is cybersecurity leadership summit focused on cybersecurity topics. You can try and either in Berlin onsite or virtually. So it's, as I said, a fully hybrid event for the webinar itself, few housekeeping aspects.
So we are controlling audio. You don't have to care about, we will do a Q and a session by the end of the webinar. And the more questions we have the better it is. So you can end the questions at any time into the code of webinar control panel, which usually is at the right side of your screen. We are recording the webinar and we will provide a recording. And the slide soon after the webinar for your downloading your convenience. And finally, also we do two polls during the webinar one, right after that slide. And then one little later, and we always tend to pick up the results of time, allows the results of these polls during the Q and a session later on. And with that, I, without further I do, let's have a look at it. First of these polls, this poll is looking at, which are the most important, which is the most important of these topics for you. Is it having really more blueprint planning for all of it? Is it multifactor password less? Is it authorization trust in time access, policy based access controls, or is it just making zero trust reality? So I'll start the first poll. And so I'll give you whatever 25, 30 seconds. So please enter your sort of key topic priority topic, the more participate, the better it is. So,
Okay. Let's say let's wait some 10 more seconds. Okay. Thank you. And then I'll close the poll I'm back here. And so let's have a look at the agenda for today in the first part, a very short one. I look a little bit at the fundamentals of password, less authentication because when you're talking about the finishing, the way the world works in passwordless authentication is clearly one of the most important topics over the past three 40, we got used to passwords, and I think we also got annoyed by passwords. And so part of the journey part of this past is looking at passwordless certification. The second part, then you can, will dive a little deeper into how hyper addresses this and sort of supports truly authentication. And after that, which is also relatively short presentation, you can, I will do more talk about some of our thoughts and then thinking about the future of authentication in specific, in the context of logging in cation cetera.
And then finally we will do the Q and a session for this webinar. The more questions you we have, the more you enter the better it is, use the opportunity to get the answers directly from, from Hanman from me on the questions you have around the subject of this, a webinar. So passwordless, it's something I honestly like, because I think we all know passwords are a risk passwords are inconvenient. They, at the end of the day cost travel, they cost cost. And it's also that if we just use username password, so just rely on the knowledge of someone, we are taking a major risk and the us cyber security agency disease a while ago has declared a single factor authentication as being sort of a bad practice. So not sufficient anymore. So we need to get better and we need to overcome this traditional scheme.
And the one I trust, I'm just showing here is already, I have to say a, a positive scheme in the sense of it assumes that we have a second factor in place OTP one time password. So we have a username and password and the, the one time password in addition, which comes from for instance, a Hartford device, or sent to us by master of SMS, also not being the most secure way to do it. The problem is the password travels travels to authentication system, which uses the password or a hash of the password, depending on how it's implemented. And that is also the place where it is whatever 70,000 or 5 million or even more passwords or passwords reside. This is where they sometimes leak. And then service builds on that authentication. This is, as I've said already, a positive one, we, we still see very, very frequently something where username password are used to access the service and by the password travels.
And I think what we learned from all these incidents related to passwords, also that we are on the right hand side, we have this point of attack, which is used by attackers to gain, to access, to passwords and to use them for their attacks, for selling them in the dark web, whatever else, modern scheme in a simplified manner, but trust, illustrating what we are talking about and what is, I think, an essential element of the future and of the, the way we are changing the login. Instead, a user has a device, the user very commonly authenticates the device or using that device in some way. They're common support for standards, which are called phyto standards, which allow to use different types of sort of device integrating other authenticators. And that device is matched to the user. So there's device key, the user authenticates, then it opens the key and then keys are traveling, which are cryptographic informations, which are not stored centrally.
So there's not this single central store of information. We then in a good scheme, also user risk engine. So we look at the context smart and accessing from where uses to access or for somewhere totally different. And then we build a Federation standards to access the service. The main point is we are getting rid of, or one of the main points is we're getting rid of the single point of, so this passport database is where, where all the secrets reside, we are moving it. We have more than one factor. We have device, which is very convenient, which standards thing uses are used to do most commonly a smartphone, but not necessarily a smartphone. So there are different ways to do it. These devices, modern devices all today have built in hardware to store the secrets in a secure manner. And so we end up as a good authentication.
That is multifactor, that is risk based and context aware that is convenient because once we have paired the device with the user, it's usually just a fingerprint or a look into the camera to unlock it so we can do it very convenient. So it's a fit to the user, to the users and the device, and we can make it work in different ways. And this is at the end. And as I've said in a relatively simple manner, the idea getting password less, but also getting more security. And this is, as I said, my, my intro to this topic before I hand over to your second question, and I appreciate honest answer. So that, that is, has your organization already suffered an attack that was caused by breached passwords, simple answers, yes or no. So did you already suffer from something where password breach led to an attack? So it looks like your answers tend to be a little optimistic here. Did I give you another 10 seconds? Maybe some more, want to answer? Okay. Then I'll close the poll. Thank you for your participation and that
Martin starting to share my experience as well. Yeah. Hello, everybody. Welcome from my side as well. Thanks for the introduction Martin. My name is Johan, as Martin said, I'm with hyper the company that fixes the way the world logs in, I'm responsible for the go to market in the continental Europe site of the ocean. And I'm here for a bit more than one year now. And yeah, I hate something. I hate passwords, which I assume all of you in this room, this virtual room have the same hate for passwords. And I don't wanna repeat what Martin just said. I actually really just wanna remind all of us about three terms about the terms actually truly passwordless about the term fishing resistant and about the term MFA, just to keep in mind, once again, I be reminded once again, what this really means. What's the meaning of passwordless.
So this is when we do not have any shared secrets in play such as one time, password solutions, no redo. There's a seat that calculates on one side, there's a calculate on the other side. And those are shared secrets, which obviously you can always, if you're attacker go after essential repository to attack to get the information that will allow you to compromise an account password list is when we use asymmetric keys, keys, well known from public cryptography mechanisms from PKI, from smart based authentication ways where there's no central compromise anymore. Martin already mentioned the authenticator. People have a device, probably a smartphone, probably a security key, a device that hosts a private key of those asymmetric key pairs. And obviously if ANCA would now want to compromise your identity, they would go for each individual person for each individual identity one after the other, there would be no century repository, more that could be attacked by some hackers.
What is possible list? Most of you are familiar with the term fighter fast identity online. The fighter Alliance are probably the definers of parcel authentication many years ago. I think in the seven, eight years ago that the fight Alliance was founded. And the whole purpose of the fight Alliance is to maintain, to create design and maintain the idea of parcel authentication at the same time with strong authentication on consumer side. But many of those approaches are also valid on the workforce. On the employees side. Now getting risk, getting rid of passwords is probably very easy to say, but is it as easy to implement? We'll see, it's a big, big difference between passwordless user experience and it truly OUS authentication, but we really eliminate those shared secrets. That's the reason why I still wanted to make sure this word passwordless is well defined and we are all on the same patient as true now resistance, we call our stuff a ING resistant MFA solution will defect authentication solution.
I think we've really heard a lot of artificial resistant MF aiming the new gold standard after the breach is reported by lapses and others, because it's becoming more and more common to also bypass legacy MFA solutions by push forming attacks by, by men in the middle of text, by spoofing information. So whenever we talk about resistant, that means there has to be no SMS. There has to be no voice calls, no OTPs, no push notifications that is resistant. MF resistant is when the user is made. The initiator of an authentication obviously approach is something very convenient. You just get a message you accept, but what if you just got 12 messages in 30 seconds, would you probably realize that some of those were real, some were not real. If you put the user into the control into the, the driver's seat of the authentication, if he will have to initiate an authentication, for example, by scanning a QR code, this would obviously give any phishing attack, any bombing attack, no chance to succeed.
Last pair, multifactor authentication with all the passwordless hype going on. We should not forget that multiple factors are still required for a strong authentication. And I think I, I, I read that sentence in one of the last events with as well, the definition of strong authentication and sorry for that, I'm reading it from the screen. Now is any method of verifying the identity of a user or device that is intrinsically stringent enough to ensure the security of the system it protects by withstanding any attacks it is likely to encounter. So strong authentication is still something which requires a number of factors and passwordless authentication is not necessarily a multifactor authentication. Often one of the theoretical factors sits on the device where I want to authenticate. So when I just use my fingerprint to log in, is it then still a parcel authentication with, multifactors probably not in many situations, we tend to combine parcels multifactor, or maybe vendors combine that on the marketing side, but we do pay attention that there's really big, big need to separate those several factors.
So what are the viable factors in the strong authentication? This hasn't changed in a while. It's the knowledge? So something only the user knows like pin decentralized pin it's the procession something the user has, which is mentioned the smart corner security key in the case of positive authentication. These are the two most common holders of private key information required to perform a truly positive authentication. And it's the adherence something only the user is. And that's the biometrics we are all very familiar with. I would say 95% of us nowadays really open their smart for by just offering their face for face cam or a fingerprint, some more advanced technologies as well, but primarily it's the Facebook recognition or the fingerprint that will allow us to just open our mobile and the same way we can make use of in which will see later on as a second.
So these were the three words passwordless truly, passwordless fishing resistant, more effect authentication. And yeah, I, I haven't, haven't explicitly said that, but ideally in most cases you combine the procession inherent that's because biometrics are still considered far more secure than decentralized thin. However, there are situations where you cannot use the biometrics for whatever reason their pin would still make it as a second factor. In those multifactor combination capabilities what's push sure is a password shall never be factor a multifactor authentication. And that's also an interesting misunderstanding, which we still see in the market that people believe a password is one factor. And the push notification of an MFA application could be the second factor. I think that's absolutely wrong to think that way, given what Martin said and how insecure passwords are, how fluid passwords are, how easy it's to steal credentials and how many credentials have been stolen over the past, over the past decade already, you can just not consider the password still being a valid factor as part of a multifactor authentication. So please be aware of first of all, any theories where the password like, you know, username password combination represents a first factor and just requires one additional factor, but also be aware of any kind of MFA solution that uses passwords or shed secrets as part of their multiple factors. Because if you subtract the password from those factors, you might end up with only one sector and are not complying with MSA anymore.
And that's the big problem because we still use passwords. If you've been in the copy or European, any conference, you are probably familiar with that slide. I've only used two of the three here in that animation that just to remind ourselves, we are logging into the active directory with a password. Majority of people are doing that. Some are using smart cards, which is called smart. It's a very smart way to authenticate, maybe not the most convenient way, but a very smart way from security point of view, but most really use passwords. Those passwords are often required to be changed frequently. They are required to be very complex. Yesterday. I talked to prospect to, to that. They've now increased their number of characters for standard user passwords to 12, which I personally find really amazing. It makes sense, but what makes even more sense you will see in the next slide would effect authentication has been in use is in use today for many applications that meets to be accessed, especially when they are resigning in the cloud.
So because you don't trust that user that has locked in with a password for good reason, they will be required to present some proof of their identity by applying multifactor authentication as a secondary authentication step. And I already call it secondary authentication. That means at the same time that the user might have to reauthenticate every now and then when accessing a new application, sometimes companies use single and on solutions. So they would only have to reauthenticate once or once in a while, but many really require MFA for the excess of several different applications, by the way, the term zero trust. It's also an interesting one. The terms request is very good fit into possible based authentication because we shall never trust that user that is authenticating with a password. This is definitely an identity could be stone, could be compromised, so don't trust it. And yes, then you have to apply MFA for secondary authentication from the user experience.
Point of view, not that password is only a bad experience, but in general, logging in once, twice, three times, maybe four times just to access a certain application is certainly not what we would consider on. It's certainly not a great user experience, what we put and should do. Instead, we should already use solutions that are out in the market technologies out in the market that provide a S login, right from when I say from the, I mean, right at the login into your ad account on your desktop, on your laptop, that's where security matters. First. It's like when you enter a house, you don't leave the door open to everybody and then just lock the rooms and make sure to prove who wants the success, which room you typically only allow a user to enter your house or person and identity to enter your house.
If you can be sure who it is, same here accessing your computer should only be possible. If you can prove your identity right away, passwordless will affect the authentication will do exactly this. And the great thing is that this puts you from a trust to a trust situation. That means that going down the road and, and accessing several additional applications in the on-prem of cloud environment could now be handled very seamlessly by trusting the authentication the has already performed on his desktop. Why? Because we cannot trust the user, his proven identity with multifactors. It could not be compromised by a leak or stolen or guest credential, so we can give the user back a single someone user experience. We don't have to, obviously, because there might still be reasons for some users that don't access the application via his notebook, that maybe the applications in such a critical shape that you really want or have to be complying with some rules that require additional authentication.
So obviously you could still introduce a risk based multifactor authentication for a secondary authentication step, but the good news is you don't have to. In many, many situations, you can just ease the life of your users can ask them to authenticate once in a strong way, in a simple and strong way to the best into the active directory. And from there, let them float downstream into several applications. How this looks like is something I'd like to show you very briefly and allow me to share my screen. You can now hopefully see two things on the left hand side. We can see my mobile and my smartphones actually here. So my hands are up the right, so you can see windows test environment. And when I start the hyper, my smartphone, you can see that because I've connected my smartphone to the screen as well. So I don't have to show you the smartphone all the time, just as a proof that it's not a trick.
That's what you see on the screen. I click one of those bubbles, which represents prepared count on this machine, and it will ask for an authentication. It will require my barometry. As you can see, I'm looking right into my smartphone and magically. I will be authenticated and locked into my active directory account on my machine. That's how simple, but still very secure OUS multifactor authentication can be and remind one smaller Fisher system term. Since I've put the users I've been initiating the authentication. I didn't get any push in notification that I have just approved. I simply start the initiation of the authentication by clicking that, circular this in my app and perform the possible authentication in the same way. By clicking that same button again, I could literally walk away from my machine and close the screen for you again. And that's actually already it from my very short demo. We promise to be very brief in our presentations and demos. There's a lot more to talk about lot more to show that here I'm pending back over to Martin for the next part of the webinar.
Thank you very much Johan or that demo. I think it was the previous demo I've seen so far in the webinar, which I like. So was very, very concise. And with that. So we are voice screen right now, post camera. Let's talk a little bit more about some of these aspects. And so we have a few talking points. And as I said, after that, we also do our Q and a sessions. So if you have any questions, feel free to these questions so that we can pick them up. And so let's get started here first and your product is integrated aspect. So, so integrated is something. I, I feel that I think when we think about the, the future of authentication, my perspective is we must IBM combine convenience with security. And when I say combine it, I mean, combine. And that balance cause balance would be one goes up. The other goes down. Doesn't make sense. That is from my perspective, something which is definitely about integration. So when you think from your perspective of about integration, what are the areas of integration to look at?
Yeah, if you really look at right, right. The beginning, I I've certainly one of those animated slides when it comes to the desktop,
Multifactor authentication is not new at all to any companies we're talking to, to any customers we are having multifactor authentication has been established for the last 10 years, but the integration of multifactor authentication at the desktop level is something I would say pretty new. It's something that legacy solutions don't offer in a convenient way. And you, you actually nailed it because more security on top of what we do already now require from our users cannot require more complexity for those users. If you would imagine to type in the username and the password and an MFA credential, whatever it is, process, just every time you log into your desktop and you do that probably five, maybe 10 or 15 times a day, you would suffer big time and you would start screening at your it. And that's where it operations. And it security get into this constant fight of balancing security and convenience. And in this case where we really have a strong, but still simple way of offering an authentication experience, a, a seamless and, and, and unified authentication experience from desktop to cloud, that is what we consider integrative hyper to allow the same authenticated methods to be used for the,
And, and I, I think one interesting thing is I I'm, I'm in this industry for quite a while. So I remember all the trouble with Q replacements, some of the ones who are maybe longer industry also remember when, when the graphical interactive network authentication component of windows systems were replaced by vendors to add some sort of stronger authentication and it frequently cause travel. So I have, I have some appraisal for, for companies which make this work today's, it's way easier to integrate. We have to be, we fair with on that, but I think it's important to have ASION cause at the end of the day, security starts, when you log into your system, this is the point where everything, everything thing starts and I'm, I'm fully with you. And at the end of the day, you know, take a stand on windows device, then you have windows, windows, you have one drive, one drive synchronize of the data you have in the cloud. So if you don't secure the system then quite early. And so I, I would fully agree with you that integrated is, is a main challenge. One of the things I'm a little curious about is so when you have, let's say older applications, so every single assemble and OS and ID connect is relatively.
Yeah.
What about your stuff?
Yeah. So that's typically the biggest challenge for any modern authentication solution out there. They're all cloud based. They're all taking care of cloud applications, but as you said, it, there are several legacy situations in companies that want to, that want to integrate with MFA as well. What we do as a vendor is we bring some pretty old, but still standardized ways like radio service that we can use to integrate legacy applications. Sometimes it's third party solutions that do nothing else then require an MFA to be performed. Even when you, when you access a fine share, for example. So partly it's thinks that we as a vendor of a product can deliver right away, partly it's things that you would probably look into a third party solution that can integrate MFA anywhere. And again, hyper would be the unified authentic experience, but technically it could require additional components to ask for more effect authentic, depending on what exactly you want to secure.
Yeah.
I think it's the honest answer that you need because the, everybody that will say modern authentication solution can just integrate everything right away. All companies look into the future and the future is everything. What what's regards to cloud, obviously the solutions themselves, but also the applications that are being connected. So you mentioned similar mighty connect, etcetera. The good thing is that there are many identity provider solutions that already do some centralized integration Federation for authentication, which has been the easiest way for us and what an authentication solution provider to simply authenticate to that IDP SSO solution.
Okay. Really pathless. You already brought up this topic. I think we are, we are on the same page when it, when we, we say it is that sufficient to just hide the password from the user. And so the question always is where, where does password cation really start? I think we, there can be arguments about it. So is it really passwordless if you have a pin, which you only use for recovery and which only exists locally, interesting question. We, we can clearly discuss about this, the blurring line. I, I dare to say, but on the other hand, if we take whatever traditional enterpri single on, where you have a wall of user names and passwords, and these are trust provided in the background, then it's not passwordless, it's, passwordless maybe even from the user perspective when, when he can open, so to speak the, without a password, but at the end of the day, it's not passwordless you brought up. I think we both brought up being really passwordless is important. Cause we don't want to have this shared secrets anymore. Maybe a little bit of tricky question to you. My, we have this cryptographic keys, which are traveling. Why aren't these shared secrets?
Because if you have, I mean, talking about traveling, if you look into the principles of asymmetric or public key graphy authentication, you don't have keys that travel, you have signatures that travel that are being made up from Keith. I don't think we have the time to really, or got the graphics here to go into the mechanisms of PKI authentication. But
You brought up the main term here already, I believe, which is as which is, it is not that this is the same secret on both ends. That's something as metric. Then I think we don't have the time and I probably have everyone. Some will be very familiar with public private key and others probably are not super interested in it. But at the end of data pointers, it's not the same information on the both ends.
Exactly
Shared
What's what's really important is Martin that the private key of those tric key pairs is not traveling, is not leaving the authenticated. As my case, what I show a demo, the private key will never leave that smartphone here it's store on the securing cloud. The smartphone cannot even be back up or exported in any way. If you use a key like key, for example, the other keys, like the security keys, if you have authentication pairing with hyper on that key, the private key will never leave this device. And that's the important thing about keys, not traveling, of course, the shared secret thing. It's, it's several different stories. Actually, the chat secret thing, make sure if you don't use shared secrets that there's no essentially attackable repository anymore, but also the fact that a private key never leaves your personal authenticator is a very strong process factor.
Because as soon as you would imagine, you have your personal authenticator on your machine as well. And some solutions, they, they implement the authentications of the private storage just on their computer. The computer might be traveling as well that this keys or the smartphone is always with you. And I, I want to make a clear line from this blur line. You mentioned a blurring line before. I think it's quite easy to say what's really passwordless. As soon as you can no longer log in with a pre shared secret, then it's possible. As soon as there's no way around this cryptographic authentication response mechanism, then you're truly passwordless and you can very much define it by having just the passwordless user experience like password managers that you, you start to mention where you have the hidden password user I password combination in the back, but you just access that application maybe with the biometrics, but still it will still end username and password that's for sure. Just possible user experience. Whereas when you work in the PKI mechanism, it's a truly possible authentication.
Okay. Pre us to an interesting question we have from the audience, which I I'd like to, to bring up here. And that's, what's the proposed recovery procedure in, in, in your solution in case the phone is lost for stolen, how do uses reregister?
Yeah, I mean, that's a very simple answer because there's no matching around that. If you lose your smartphone, it's like if today you lost your password. There's no other way than getting access to a help desk that will allow you to access your system. Now, the different methodology that we use, instead of what's being done with a password today, there's no password reset that somebody would then allow your password anymore, but still you will need to get some kind of recovery pin that will allow you to log into a system for the time that you don't have your phone for the time that you not your security key. Ideally you'll find ways to replicate a phone and a security key, or that you always have a second phone where you probably have your authentication registered or paired for the authentication that in the case where you just have one authenticator, there's no way around to, to go to Kaza, go to the help desk and identify yourself in an operational way as you would do today. If you lost your password, if you lost a smart card and get accessed by being provided a recovery pin that is started for such a short amount of time, that it still allows you to reregister new authenticated device that is small enough to not allow to be used to,
Which brings us to resistant. So third party in this, I dare to say also part of resistance. I, I have a strong belief that the password authentication is relatively difficult to trick by, by, by fishing. So you can call and say, oh, I need your password. But the tricking someone to reregister is already a relatively complex issue and tricking someone to, we were a sister in a way, or to, to provide information for that. Yeah. Take a research is assist device where otherwise with the, with together, with the whatever other, information's definitely a very complex task. So what do you say that procedure also is part of making the solution really resistant?
Yeah. I mean, the question is always where you want put your, sorry, where you wanna put your focus on. Obviously there will always be situations in every, in every authentication methodology, not a product, but a methodology to authenticate. There will always be situations starting with the registration process, the initial registration process, but you need to make sure to prove an identity in a different way. There's always situations where you have to have additional organizational measures to really prove an identity. The point I'm making is sufficient assistance that in your daily authentication process, where it's become pretty simple to fit information to school information, to get around legacy MFA solutions, you need to be really in, in a, in a simple fishing re need to be operating in a very simple fishing resistant way that I think now technical solution can really exclude organizational measures again for the registration process for reregistration process, where you have to find ways to prove your identity.
Let's call it by legacy methods by real methods that it can never replace with the technology itself. It's, it's similar to many other situations that I, that I have in my mind where you can just not go around some organizational process. And that's the same here. Okay. So in, in this worst case, or in this case of a, of a device loss in this case of a destroyed device, there will have to be a process to prove your identity. So you cannot be tricked to, to register a wrong device or, or to, to wrongly register your device,
Brings us to multiple devices. How do do we deal with multiple devices? So many, if, if not, most of us have more than one device
Also again, there's different use of mobile devices. So one, one view is that you, as a user will probably have to access several different devices, either it's just your devices or it's the devices that in Ks mode where you access, but also other success, sometimes other people have to access your device. I think that's exactly where, where it's becoming quite challenging for many providers of, of so-called passwordless authentication solutions, because it really often, these solutions often require one-to-one relationship. You can register yourself on that specific device, especially when you register your biometry there. When you store your biometry there, when you store your private key information, there it's that device where you can only register. And then later on log into, you've seen in my demonstration that I've used an out of bank device on my smartphone, which stores all the relevant information, which uses my barometry.
So I could actually run to every system in our organization and simply authenticate there. If I had another computer for myself, same thing here, I could either register to that device once more. So I have two register device, or I just make use of my registered domain account on one device and can simply run up to the device, still log in there because I've registered an account rather than device, multiple device. In terms of authenticators, if we take a different view, could be that you use a smartphone and, or a smart security key as an authenticator. So they cross multiple devices as authenticator. So there's different ways to look at it. I think it's important to say that there's, you have to look at each individually from, from what angle you look at, but it's also solvable. Actually, if you have the right solution in place, you can get Roman users to access the same system. You can get multiple users to access one system. You can get one system, one user to access multiple systems. You can have multiple authenticators to access the same system. And obviously you can also authenticate on many devices and applications with one solution. So you would've to back quite a complicated answer, but it's, it's solvable.
Yeah. But, but at the end, what you're saying is you can use same device with multiple accounts and you can use your account with multiple devices, correct? The end that's long, long story short brings us to the Q. We already have a couple of questions here. And again, I invite the audience to, to up more questions. And I think we can pick some of these questions we have here. We already answered one of these questions. So the first one is assuming that what hyper offers is at least partly a cloud service, this the backend side, how do you use this login when they are offline? You already brought up your sample with the offline, but how, how does it work greatly?
This is a quite common question. Actually. It's one of the most common questions we're receiving. You see my smart, my screen. Again, there's a pretty smart way to do that because you, what you wanna avoid by all means, if you go truly, you wanna avoid that users need to fall back to authentication. You need to want to avoid the users, get back into the password potential provider, having to turn in a password. Why? Because once they really went passwordless and forced not enforce, that means they won't have to password anymore. If it's enforced, they can't even use their password anymore. So what you want is a mechanism that allows you to remain in that specific customer trans provider with an offline login and offline login is something which happens quite often. You're in the plane, you're in the German train systems, always offline during hotel.
You actually open your app and push that button a little longer and you will get an encrypted key. You see, only when I open my barometry, I can now one of, probably 30 offline pins I've got created on my smartphone. The last time I was online. And I now trying to track it in at the same time as talking quite challenging again, but I can just use one finger here on the right side, in my notebook. And if I didn't miss type, you can see I'm not in here. So the answer is there's an offline pin mode where you can very simply and still convenient allow you just to access the system in any, anytime the system would be down on one system would not be available at the time.
Okay. Thank you, Craig. What about admin access?
So
You locked in as the user and then you do some admin activities. Okay. We could be soon and say, okay, most admins anyway, used to same account still, still, but it's a good practice to say I have different accounts for, for different administrative activities versus my sort of standard user account. So it's,
I, I think that question must come from somebody that is probably working. If they are already often indicating password list, then it's probably from somebody coming that is using something like hello for business, where you, where you pair your, where you don't pay your user, but you pair your system. So you actually log in with a fingerprint or with a windows into your machine, but then once you do something as an administrator, once you need the privileged activity access with your admin account, then you will still have to type in a password. I just assume this is where the question's coming from. Yes, there is ways I can't show it in my system actually, because I only have a local account here. Another domain account that you can seamlessly integrate the authentication of hyper in the user account control process. So rather than typing in a, probably 24 character password, you would simply scan a QR code. So again, put the user into the initiation of the authentication process and then choose your admin user that you have paired on any machine and use that for authenticating as an admin and perform your activities.
Okay. I think we have now one more question, which we, we can, can grab. So, so, so that question, you brought up this UBI key example, which types of devices do you so to speak? Porwal alternatively. So what is, what do you have as options here?
You mean as authenticators?
Yes.
Yeah. So it's, it's in fact mobile phones, smartphones, they either operate iOS or Android and it's any type of security keys that can offer a combined technology of final for final two authentication or final authentication and P the personal identifiable verification. I think it's called protocol, which is used in smart counts. The first one is used for any type of web authentication. And the second methodology is used for desktop login. That's where the requirement for smart count support or P support comes so could be UVS, which is what we see primarily in, in Europe could be keys from, from Asia, could be Google Titan, all those keys that support these standards can be an alternative authenticator to smartphones or an additional authentic to smartphones as well.
Okay, great.
Just one important thing, Martin mention that some people ask you, but I could, I could use such a such UBI key on my own. I don't need hyper for that. It's true, but you wouldn't manage it. And I, I don't show it to you now because we're already, almost over time that the, the beauty with combining a password, less authentication platform like hyper with additional authenticators is that those authenticators will be centrally managed. They can be centrally configured, centrally managed. They can be de connected as well. And that's a big, big advantage for any larger enterprise that does not want to just send a key to somebody and then it's floating and you have no idea what's being done with that key, whether it's register for et cetera.
Yeah. And it's interesting. I look to see that for instance, five, two key key management becomes an increasingly large challenge for organizations out there. Yeah. So at the end, without the management, it doesn't help or doesn't solve all the pros. It helps, but it's, it can, it could be done better. So we need this measurement Johan, thank you for all the insights you've brought and sort of demonstrating how this works in, in practice. Thank you to all attend of this call webinar for listening to our webinar. Hope to have you soon back in one of our webinars around one of our events and thank you for, to prefer parting this webinar. So thank you very much.
Thank you, Martin. Thank you everybody.
