So first of all, I'd like to understand who is in the room here. Just from my understanding, are there any developers in this room, like software developers? Few.
I see 4, 5, 6 hands. Okay. Any architects? Even more hands. Okay. Just from a, from from a start, this is not going to be a deep dive into technical questions. If you have those, feel free to join. We are obviously going to be here. This is Dennis, our domain architect from im, and we are both going to talk about this topic for a second. Maybe a little background. We are a DevOps team, an identity centric DevOps team in the company Mac. So this is a global company. You probably know it, probably not.
We are regulated, heavily regulated and we are trying to develop everything on our own to understand what it's actually about. And regarding zero trust, which is probably why you're here.
The zero trust or fishing resistant journey. We took the decision to start with fishing resistant and in peril or afterwards dive into other topics. So fishing resistant is for us the most important part and it has to be something that is a one size fits all solution. So we don't want to categorize any account types like is it a privileged account, is it a test account or is it just a standard account?
We don't want to look into applications, we don't want to to check if this is a very important application or not. We don't want to check the permissions within the application because we want to do everything in the backend without talking to our application owners. Because it's a very big company. One size fits all is the most important part. The goal is to deactivate SMS call or any authentication apps out there.
We want a phishing resistant authentication for the entire company.
So we did that and we want to talk in the next few minutes about it so that you know what we are going to talk about in the first place. It's going, it's how we went passwordless and what it looks like. The second one is how we enforce the password list, the biometrics and pin based passwordless sign in for the entire user space. So no SMS call or authentication app.
And then we want to talk about how this works with the apps because you might have apps in your company or you will very likely have some that don't support the standard no web or then they are very prominent examples that simply don't work. And well you need for that too, some kind of front end for the users, a self-service where they can register their biometrics or pin. You somehow need to know who is that person and you need to identify these individuals. And that's basically it, I guess. Yeah. And at the end it's going to be like a a key takeaway slide.
So if you fall asleep in between, don't worry, I will wake you later on and then it's all on one slide. And with that I will start with an introduction for the user. This is how, how it looks like for the user. There is a number
Of cyber attacks has exploded. The gateway into our digital world are our accounts and passwords. So we tried to protect ourselves better by making our passwords longer and more complex and once again longer. We introduced shorter and shorter intervals in which passwords must be updated and two factor authentication.
The problem is all these solutions only make us a little bit safer. Unfortunately, they can be easily fished and abused from the outside time to fundamentally rethink things simpler and safer with Fido.
FIDO stands for fast identity online. This standard requires a physical device to access the Merck world as we know it from a key except that a Fido key looks more like this. The Fido key must be first unlocked like here with a personal pen and a physical touch of the key.
Only the physical device completes the authentication, which makes it particularly secure against the usual phishing attacks. The good thing is like the Fido key, you can also use many other devices as Fido authenticators. For example, your office computer with windows.
Hello, pin your smartphone with face ID or with a device with fingerprint. It's in your hands. Register all your phyto authenticators in the credential self-service Porwal now and soon. Log in without any password no matter where you are at Merck in safety critical production at the office, in the home office or on the road to the customer's site. It has never been so secure to log in to our systems and never so easy to become a cyber hero.
As we have seen in the video, the identity based attacks and breaches increased significantly over the last few years.
Hackers don't break in, they sign in. Our mission is to secure our company against those threats and we believe Fido plays a major role. It is a solution for all of these problems because it's easy to use faster and more secure. It's a new way to sign in instead of password and second factor, you use a phyto credential and the user approves the sign in with the same biometrics or pin that you already uses to unlock the device.
PH eliminates many of the current attack vectors like password boot forcing, MFA bombing, Zim swapping and so on.
But most importantly, it is fishing resistant by design. Fido is an open standard established by the fighter alliance and backed by leading technology companies like Google, apple, Microsoft and so on. We are really happy to share our fighter journey with you. It started two years ago and we decided against the software as a service solution where all the pH credentials are stored by a single provider in the cloud. That is something we don't want. We want to have full control. Our primary guiding principle is to own the credentials and to own the authentications.
And since there was no off the shelf solution available, we started our own development journey.
Good. Let's look at it. So as I said at the beginning, it's not going to be very technical, but you can see what it looks like. Hopefully this is the Passwordless sign in. As I said at the beginning, we talk about biometrics or pin, and for the user it looks like that. On the left hand side you see our credential Porwal, where the user can register an authenticator. Authenticator means biometrics or pin from your, I don't know, iPhone, from your windows, hello or from a security key.
And when he tries to sign in on a web application somewhere, you can see this screen biometrics or pin login, oh, it's a German one. So everything English, German, perfect. It's a login with biometric or pin. And then you can choose between phase fingerprint pin, whatever is available on the computer at that, on the device at that time. And of course it can be extended with a security key or card, you name it. This is what it looks like. And you can also see that we still have in this stage the s m s call an authenticator app enabled.
So right now you could also go via a password approach and then a second factor. This is I will explain later on. Very important for our existing users, not for the onboarders obviously. Good key takeaway from this slide.
Password, no longer no sms, no call, no authenticator app. It's a phishing resistance sign in with biometrics or pin on the device in use.
Good. Let's turn this red switch to green. Let's disable the authenticator app or authentication stuff that you have anyways in your company and focus on Fido only. There is nothing else. There is no fallback, there is no exception.
Now the user can sign in with biometry or PIN only for all applications and for all personal accounts, at least for the account that is activated in here. As you can see, it can be enabled and disabled by the user. This is very important for our existing workforce or users because they have to get used to it. You can imagine, and not everyone likes it. We have in our company, it's a global company, a workforce that works in a laboratory or I don't know, in somewhere in a production side. And they have methods they, they don't probably don't even have a device.
So they have methods like a phone at the moment that everyone uses, which we don't want. But for them we need to provide a key or a card. So we have to make sure that it is based on a user. The enforcement and the enforcement can be centrally enabled after a certain time. So if a user registers I know laptop or security key, then we can say two weeks later it's enforced automatically but he can play with it to get used to it.
Good for new join us. It's completely different. And new joiner will only know Fido obviously for them it's very simple. It's simply disabled.
Yeah, this is the the signin part and the enforcement key takeaway. We can enforce this biometrics and pin signin for all applications and for all users. But there is a challenge that Dennis is going to talk about because there are applications in your stack that use modern authentication but not replica and ready.
Yes, as Andreas mentioned, we are able to enforce Simon. And that is a very important point because having conventional MFA still in place means that the user is vulnerable for downgrade attacks, resulting in the problem that the user can still be fished only Fien enforcement unleashes full fishing resistant. And to enable that strict enforcement mode, all applications must support the Fido standard. But there are many legacy applications which have web views that don't support it. And that is a big problem.
We developed a detached authentication flow, which you can see here in the background. And with that mechanism, the users are able to sign in by a Fido in a fishing resistant way, even for legacy applications with Fido incompatible web views, meaning we can enforce Fido, our Fido authentication flow is implemented centrally at the IDP level and we developed custom plug-ins for every identity provider that is used in our company.
And these plug-ins leverages the centrally stored phyto credentials on our self-hosted infrastructure.
Because we own these credentials, we do not have any vendor login and we can basically use them wherever we want. But what about legacy applications that cannot be connected to an identity provider via OMI Connect or sam, something like this. We can enable also Fido Forze applications by utilizing an identity based proxy or the traffic to the application is routed through the proxy and the proxy is responsible to authenticate the user before forwarding the traffic to the application. Therefore also these legacy applications can be secured with FI door.
What are the important key takeaways regarding signin? We achieved a passport list and phishing resistant signin. It's available for all applications, even legacy ones. And that is very important to be able to enforce the final sign-in. And the final authentication flow is implemented by IDP plugins. And all of these features are begged our by our self-hosted infrastructure and our centrally start pH credentials. The credentials have service is like a framework. You can develop custom flows and integrate them. We started with the password reset flow and added more and more flows on top of it.
For example, onboarding new employees or registering new phyto credentials. And the PHY registration flow guides you step by step through the process and provides additional help if necessary.
A phyto fighter credential is bound to a single domain, but due to legal reasons, our company has two domains for authentications. Therefore we implemented a specific feature where you can register multi multiple domains and we recommend to the user that he registers all of his, all of his devices as pH credentials so that he's always able to sign in with the device in use.
Security keys can also be registered, but they are often used for special cases. For example, protecting highly privileged accounts. And there is another reason why it's essential that the user registers many FI credentials as many as possible because then the user is always able to authenticate with fi. Even if one FI credential is broken or lost.
Once the sign-in is strongly secured with Fido, attackers will probably look for other opportunities.
They will search for the weakest link, the chain, and often that's a case for onboarding and recovery scenarios because fight was not yet registered due to onboarding and on the recovery scenario it cannot be used to whatever reason. Therefore, onboarding and recovery flows needs to be heavily secured. Ideally they are also fishing resistant and that is the reason why we need a sophisticated identity verification flow for those actions. And the credential staff service also provides a framework for the identity verification flow.
You can implement verification and change them together, but, and we'll dive a bit deeper into the details.
Sure. So signin method, again, one important thing I just realized when I look at it, we talked at the signin at the beginning, this is OB obviously into the applications. Now we are talking about our self-service and here we have a signin too. You need to sign into the self-service. And here we have to have identity verifications. Obviously you can use your biometrics or pin, right? You can. You can use your registered security key if you've done that.
But then as you said, if you have not yet registered anything, if you are a new joiner, if you're a new user or if you have lost your computer and your phone, if it was broken, whatever, then how do you recover the account? How do you claim ownership? And here it gets tricky because think about it, what kind of data do you have of your identities?
The identities that we know usually have a name and usually they come with a phone number but not always. Sometimes with a mail address.
Again, not always, but there's a little bit more. For internals at least we have a bank account and that can be leveraged. And of course we have organizational information, meaning every employee has a manager or a colleague. And this is what you see here. If you want to sign into this Porwal to register something, reset your password, you name it, do some action, then you can use the biometrics or another method. It's chained down here. This is an example where you use, for instance, your phone number. And this is a development that we have done with Mobile Connect.
It uses the e, the Zim card or the E Zim card. It is a phish resistant flow. It is sim swap resistant and it can be used with a lot of phones or with a lot of m andos, but not every m o.
There are a number of other methods out there. The point is you can chain them in the Porwal to achieve a higher security and ideally you have a phishing resistant identity verification at the beginning and then other words, other ones afterwards. Once you have done the sign in, the identity verification, in whichever part, you can obviously switch the device. We just talked about the the mobile phone number.
If you have done this on your mobile phone, then you have to somehow switch to your computer if you want to register it. This is why we had to implement a device switch because now you need to switch with that session to your device. It has to be phish resistant, the switch, and then register your windows or whatever it is.
And yeah, this is the, the sign and process key takeaways. We have an identity verification for every registration. You cannot register anything without the identity verification at the beginning. It can be used for onboarding and it can be also used for a standard password reset.
That's it.
We have, I'll do summary. Sorry, that's it means we are done with that stuff. But I will briefly run through it and I will just realize we have a complete summary. But here the stuff that we just talked about is about onboarding recovery processes, which are a self-service. We don't want anyone from a support team to be involved. They cannot be involved. You have to go through the se self-service. There is no other way, which is nice from an automation perspective and additionally nice from a security perspective. Then we have an identity verification with several versions that we can use.
We can use the biometrics of the current device and as you said, we use multiple domains. And the summary for the entire presentation is this one. And at this stage I would like to open the discussion for a q and a. Is that fine?
It's, it's fine. No, I get first
Question.
Yeah, the, you mentioned dual domains. Do you have a separate key pair for each domain?
That's true. And we have it somehow added behind each other, the registration process so that it's convenient for the user. The domain switches behind the scenes and the users prompted for the next authentication. Sorry for the next registration.
Okay, we have an online question here. With past keys, is it possible to have FI keys at the device level instead of the user level to have PS PST two compliance?
So right now it doesn't work for for Apple. Maybe it comes in the future. I know that they're talking about it. Initially it worked actually before pasky were allowed, but then the PASKY was introduced. It's for us, not a big topic at the moment. As we said at the beginning, we want to secure the, the sign-in, it has to be phishing resistant.
The next step then is talking about how do we make it more secure from a credential level? Where is it stored? It's this also phish resistant so to say.
But for, for the Apple devices isn't, it isn't, I guess for the Android devices either. I didn't check to be honest.
And and we hope that there will be so, so there is outlook about this, right? It's coming with Web OS and three hopefully sooner than later. So I think also that there is a meeting of the fighter alliance next week or so in Dublin and maybe they will discuss, so maybe the community community can push a bit into the right direction to release this device public here thing and then the next time. So that would be cool.
Thank you. Questions.
Speaker 10 00:22:44 Excuse me.
Speaker 11 00:22:47 Thank you. A very interesting presentation. How do you manage user adoption? You explain. So the mechanism say, okay, end user and role key, key, and then in one moment the other authentication are closed. How do you manage to get the people train enabled and ready for staying on Fido?
So it's terrible for on onboarders. It isn't because they simply don't have another option. But for those who are existing users, it's obviously a convincing topic. And at the beginning you can play something, you can play softball, right?
You can say, Hey, there is a little marketing. Each time you log in, you sign in. Then there is a little marketing switch to a faster sign in, click here, forget about the password next time. Then you can click it and you're in the registration flow, which is very neat. And it would recover and it covers a certain range of people, but obviously not everyone likes it, which is actually the state that we are in right now. So we need to convince those who don't want it. And there are completely different aspects of it. At the beginning we talked about people who need a security key.
This is a global environment, so it takes a little time to do this, but it's, it's feasible. And if you really wanna play hot ball, which we eventually have to do, then you can think about any other method as soon as you don't do it. We simply reset the password in a very often time state. So really annoying stuff. You can get people to do it, but they don't like it, right? You can't change it. You need a strong marketing, you need management that supports it. You need people who are champions in your company and take it there. But at that point you cannot really do anything to to push it.
Speaker 11 00:24:36 Thank you. Thank you.
Speaker 13 00:24:38 Other questions? Hi. Thank you. It's sort of a multiple question for the current users, you've got the alt authentication mechanisms and the new fighter two mechanisms. So if they lose their five two key, they can then fall back to some of the older mechanisms if it's still enabled. But what do you do if someone is new? He gets his five two key, he registers and he loses that key. What's the recovery procedure? Cause they've got self-service with identification, but he's only got one device for multifactor.
And that's now lost.
So first of all, you can register your computer and you can register your phone. Most of our employees, they get a phone and a laptop and they need to register both of them because otherwise you can't work with it. It's phishing resistance. So you have to register to the device itself, meaning if you lose one, you still have another one. If you additionally add a key to it, then they have three things that they can use. But let's talk about the person who loses everything for whatever reason. This is why we talked about the identity verification at the beginning.
You have to have some identity verification. And the only identity verification that we currently have that actually applies to all our workforce is we are using it for the internal workforce as of now is the colleague factor or the manage, let's call it manager or colleague factor. It means that in our web
Speaker 13 00:26:13 Of trust, basically
It's at that point it's trust. Exactly. So it's in the credential Porwal and then they're connected and then they exchange, they have to talk to each other and exchange in a one-time password and we can change it with other stuff.
So maybe the person has a phone, you can do the zoom card verification with the m and o, the mobile network operator, or you have other information that we can leverage like micro-transactions to a bank. Maybe you have already implemented some kind of video ENT stuff that you can change together to make it more secure. But at that point we are talking about identity verification and no longer about the fighter standard, obviously.
Speaker 13 00:26:56 Okay.
But that identification, identity verification, you don't use any fishable information like the bank account number, anything you mentioned earlier,
The mobile connect is not, phishing is phish resistant. You cannot fish it, but it's not globally available. Not every mobile network operated supports it yet. But this one would be good. And then there are other ones which, which are technically probably fishable. But if you go a long way to chain of the many of these things, then it gets more and more unlikely that it can actually happen.
And for the more we, we have a context basically, and we, we provide the most secure chain of authentications or identity verifications that is possible for the user. So it's kind of clever somehow. What is the securest way to recover here? That's the first point. The second point is we push user's heart to register as many as possible pH credentials. So that's the likelihood that the user has to go through that pain because it's, it should be pain. And it is pain by, by design and by intention is not applying to many users.
So I don't know, having a 90 to 10 coverage or 95 to five or something like this.
Speaker 13 00:28:26 Okay, so from what I understand, you say you've got the multiple photo two devices registered per user and they have to get the acceptance from them, not just register one new device, but two or more devices. So it's an acceptance problem as well,
But they, they have to, because otherwise they can't use the device anymore. So at that stage they will have to do it because otherwise they can leave the device at home and don't use it because they can't sign in into any application.
So it's an intrinsic thing. A little bit maybe.
Speaker 13 00:28:59 Thank you.
Okay.
Just, just clarify, there's not necessarily, it'll all depend upon corporate policy. Like if you, if you, if the corporation in this case wants two devices so that you can have that redundancy, somebody leaves it down. Yes. If you don't want to do that, you don't need to do that. You can say, well, that person that left their US speaky at home can't log in.
So it's, it's up to the corporate. Just like a smart card. Yeah. Don't have a smart card. You have to have a process, an out of bound process to deal with that.
Anyway, our time has gone, so we're now going to convene the next event, which is the panel. And we have, and Andreas is going to stay here on.
