A Story About Convenient Security

Good morning, everybody. I think my mic is working. Welcome back in onsite conferences. I'm actually somewhere between nervous and excited to be on stage. Again, spent some time and I, I missed it feeling of stage fright, which I had when I was standing there. The last 10 minutes, getting up here. It's exciting. I hope we had a great evening yesterday. Beautiful, warm evening in Berlin. So you keep in mind today. It's raining. So please everybody stay inside the whole day. My name is Johan as just announced. I'm from Hy beautiful city in the Southern part of Germany. And I wanna talk about password list today. Password list as a story about convenient security. And by starting this, let's see if this works so far. It, now it works exactly. I have to see what you see here. Great. So I have 20 minutes. It's pretty, pretty hard to put 20 years of it.
Security development, or non-development into 20 minutes. Still give it a try. Maybe ending up in 15 security and convenience have always been a balancing act. Never has there been a conscience between has to be very secure and very usable. There's literally no products on the market that do this because it's always a fight, a constant fight between it security people to create a lot of security. It operations people to try to create a great use experience. On the other hand fight between the user happiness from their side, the enterprise protection, it just doesn't work out well. The thing is we are used to do things that are not great. And one of those things that are not great is we are logging in with a password into our systems. We can debate about the user experience. We can not debate about the security actually. That's something which we're doing for many, many years, I would say for two decades now.
So I'm 20 years ago, this this started and it actually wasn't that bad back then, because back then we had a single cell on solution. So actually it was kind of a good user experience typing in a password once probably eight or less characters back then. And we felt pretty safe to be able to access almost every application in our on-prem windows, whatever environment, very rarely we had to use another password to look in somewhere else. Sometimes we were asked to use MFA for VPN access. I think back then we called that remote access, not VPN, but there was no secondary authentication that that required an MFA to access some application. Cause we had no cloud applications. We had no specific areas where we were asking for MFA that was just not there. And actually the term of zero trust. I think it didn't exist back then.
At least nobody ever talked about it. The interesting thing is where are we today? And the current set of authentication when logging into my active directory account, guess what? It's a password. We are 20 years later, we're still using a password to log into our computer, to our laptop desktop for our ad account. The big difference is that today because we can't trust that user because he just used a weak authentication method or password. We ask him for multifactor authentication to access other applications. So once they access, I don't know, M 365 or any, any single sign on identity provider solution, we automatically are being asked for MFA. And interestingly, the MFA often is just another password. So we protect the excess with probably one plus another password or at least the password based MFA solution. So as I said, this is done because we don't trust that user because we cannot trust that user. However, the experience here, I think that is not debatable. This is pretty poor. I talked to a couple of people yesterday already, although it was only half a day of conference people log in in the desktop, then they have to authenticate for the VPN access. Then they have to authenticate for their identity provider, single sign on solution. So that's often a triple or quad drop sign on before you really access applications, you would like to do anything in.
I said it 20 years of development in it security, and yet we are still using passwords to enter our it infrastructure. I think that's pretty poor. I've been in the it security for 23 years now. I'm no longer using passwords. Actually what's even worse is that we are reusing passwords as part of multifactor authentication. And we have to, we have to really think about that. That even with password managers, for example, we protect our passwords with just another password. And although we all know that passwords are not great, we do it probably don't know how we could do any better. Let's pause a minute and think of what past would do with us. That's something that I, I haven't just thought out of my mind, this is something which I have asked in several workshops. We didn't have those conferences, but we had a sum of workshops and webinars and I've asked the audience quite frequently what they feel when they think about passwords.
One of the emotions that is coming very often is it's annoying. Passwords are annoying. Passwords are cumbersome. Passwords are time consuming if you enter them, if they have more than eight characters, which typically is the case nowadays they're cumbersome and time consuming. Passwords are old school that's for fact, actually, and an interesting emotion was fear. I think that's primarily not the bus, the business related logins, but it's the privately related log ins. If you have to subscribe for yet another eCommerce side or insurance online, online access site, you will typically be asked to enter username and to create a password for yourself. And you will ask yourself, will I take the same password I'm reusing every time and will I just risk that it's going to be hacked at some point and can be reused by an attacker or do I create a new password freshly for my memory, which I will very likely not remember in two weeks of time or in two months of time when I have to log in the next time.
So the fear is just there that I either forget my password or somebody can actually compromise me by using my password when it has been hacked, it has been leaped anywhere, but passport's also formed facts. There are possible policies out there and they have definitely gotten stronger over the last 20 years from eight characters, maybe from six characters to eight to 10 to 12 often I think admin accounts were between 24 and 30 something characters. So that's really something which has been creating even more friction on the user's side. That's an interesting one. The reuse, that's also kind of a statistics. The reuse of passwords does affect it, managers, it security people reuse passwords, the same passwords in many applications. We should be the ones to explain our folks on the user side, what to do, right, what to do correctly. But actually we do it ourselves because we're just also only human being human and being human means.
We can't remember as many passwords help desk is effect help desk is heavily overloaded. It seems that 20 to 30% of help desk tasks are related to password resets, not talking about the time consuming for the employees that cannot access their systems during the time passwords have to be reset. I think everyone here in the room went through this once or many times already. Definitely do passwords, provide an attack surface, probably the most prominent one. I think it's the number one attack surface. Number one reason why systems are being compromised is because passwords leak somewhere passwords can be guessed and passports are used by different kind of attacks. And another fact we had it already. It's an emotion, but it's also fact passports are old school outdated. Shouldn't be there anymore. Talking about the threat there's fraud, obviously probably on the private side of things.
There's fishing. Again. This is probably the, the most common thing everybody talks about. Everyone knows about it. And it's so, so simple to being fished. And I would also assume that everybody in the room once went through a fishing test maybe, and didn't pass it. I include myself because I'm on the phone. I get an email, I see something with a new vacation plan. It looks great. I'm excited to have probably one, one more day in my company. I'm clicking something. What happens? Oops. It was just a test, but I failed it. And that's pretty awkward. Being in the security industry for 23 years fails such a primitive fishing test. It happens to all of us. Credential staffing is one of those names where you, where you use passwords for a text and obviously ransomware, many ransomware attacks are only successful because they can use the stolen password.
It's interesting. If you think of the other way around, if you got rid of passwords as a log in mechanism, as a, as a kind of authentication method, you would probably be safe to or resistant to 50% of all ransomware attacks that could happen. It's just 50% that it's actually after all it is 50% that you would no longer suffer from. I make an assumption now and I hope I'm right. Every single person here in the room would like to get rid of passwords and would like to eliminate them altogether. So let's fix the way the world locks in. That's what I believe, what I, what I trust, what also my company hyper believes in. There are ways to fix the way the world locks in it's fundamentally broken, but there are a number of ways to achieve that. Now, what does passwordless mean? Actually, I think there's a big buzz out there.
Some of you might have read Theil last week from Google, Microsoft. I think apple was in there claiming now in the next 18 months, users won't need to use passwords anymore, which is a great claim, actually talking about fight or the fast identity online Alliance. There are great me mechanisms out there already for many years, what we could do, what website providers, eCommerce providers could offer users to no longer having to create a password and registering problem is that these ways are not being used of being implemented because many people just don't know about it. And there's now really coming a buzz about passwordless but often passwordless is not really passwordless. It's easy to say getting rid of passwords is the way forward, but the problem is that many passwordless solutions are just passwordless user experience. They're not really truly passwordless. They still use shared secrets.
And even if it's not called password, a shared secret would mean the attack surface remains. You still have as an attacker, the opportunity to go after one central storage of credentials. Whereas if you would be truly, passwordless not only for the user experience, but from the technology point of view, talking about public geography based on what Fido is actually you would have to, as an attack, you would have to go after every individual to really compromise their user account, which is obviously a big difference and no longer, really interesting economically for many attackers, if they don't really are spice of a big nation,
This password is one thing. The other thing for a secure authentication obviously is the multifactor side of things and password multifactor authentication. And I have to read this because I copied this from, I think from Wikipedia. What, what strong authentication we used to call multifactor authentication. We used to call it strong authentication. I think some 20 years ago, it used to be called strong authentication, which 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 the question here is can a password still be reliable factor as part of an MFA process, which today it often is? I think it's a clear, no, it cannot what we should. And what we could be is one of the last slides I have for you.
And if you like the drawings, by the way, my daughter was a great help here. And if you want to hire her for some of these nice pictograms, just let me know. I have to pay every time I do a presentation and today's the first one on stage. I think that will be quite expensive. We should perform a passwordless lock in, into our active directory. The means are there already the possibilities are there already? We should use things that we have security keys, mobile devices, authenticators that have the capability to no longer use shared secrets. You all know smart cards from 20 years ago. Problem is most of you don't use smart cards because it's again, kind of cumbersome user experience. You have to distribute them, you have to manage it. They have to have the smart, have to put it somewhere in which today is not so easy to put a smart card in somewhere, by the way, you should combine the password.
Let's log in into the active directory with a multifactor authentication and that's for a good reason, because we were always talking about security and convenience. We want to use these two terms in one sentence. So let's achieve security by starting with a true passwordless MFA when logging into your directory account then, and that's an interesting one. Can, I've been talking to a number of people yesterday about zero trust, and everybody's talking about zero trust. I think it's the number one thing in the mind of CSOs, maybe even on in CIOs, if they don't think about ransomware, they think about zero trust. And we convinced everybody that we have to go for a zero trust architecture. If we remember for a moment, why? Because we couldn't trust that user over there to be locked in, to be identified with his lock in with a password. So let's think about it again.
If we manage to identify that person a hundred percent, by doing a multifactor authentication, right at the beginning of their it journey, right at the start of their login into the desktop, could, could possibly trust that person to then access several other applications, which today we would ask for another MFA performance, we could get back to a real SSO user experience. That's the convenience part of it. It's a bit tough, I think, to, to really put that in our minds. But we have got to the point where we just didn't trust the user don't trust the user anymore. We could restart to trust the user and get back to real single sign on. We don't have to though. There's obviously still good reasons for many situations where we still want the user to perform another authentication. Just to really double check, verify, step up. I don't need to teach you for the many reasons that we could allow many users in many cases to just do one authentication, that access majority of the work applications that they have to access.
So community access secure is nothing which is too hard to achieve. It's actually something which can come true and we are there to really help you pave the way to get these obstacles. And the passwords in my words are the obstacles to get these out of the way and make sure users have a frictionless experience all day long, logging into the desk, performing their work and not bothered helpness anymore with any parcels that need to be resetted because they haven't been able to log in. That's pretty much it. If you would like to hear more about this, I'm here on stage. I don't know if you can ask questions right here. I got three and a half or four minutes left. You can stop by the booth. We here in the conference all day. Thank you very much for your attention and hopefully see you sometime again. I did thank you some time.
Thank you so much for that excellent presentation. And you've excited a lot of questions from the audience. So the first one is what do you think is the biggest blocker for end users, adoption of password as logins?
That's a very simple one. I think people are hesitant to change in general. Whenever something is really a fundamental change. People think twice, if don't just stay where they were, it's the comfort zone. Even the comfort zone. That's probably the biggest blocker that we see before we can move into a fully passwordless user experience.
Okay. Where do you, how do you suggest to start the passwordless journey focusing on internal users first or what,
When we talk, when you say internal users, it's probably the question whether internal users or, or supporters, I think there's, there's no clear rule or no clear pathway. You should start actually, every user that does no longer need to use a password for a login is a more secure and a more happy user. So it's really something there's no all or nothing. There's also, no, you have to have these users, many companies to start with their privileged users, just because they don't only have their personal accounts, but also have their privileged accounts with those very long passwords, which is quite nasty to type in every day, many, many times.
Okay. Wow. How do you handle Azure ad MFA and the hurdles with the revocation type token and deep links to fat client, Microsoft apps like teams.
That's a tough one. I would suggest to get back to the last slide, come to our booth number 24, because that's a longer answer. It's not as difficult to really do an MFA into the Azure ad, but it's a, it's a bit more of an explanation when we talk about those deep links.
Okay. What, which technologies do you see to enable a clear passwordless experience?
I would really put a lot of bets on the Fido stuff. I think there's good reasons for this pH lines to be in place for many years now into more and more consumer based of indication solutions to adopt that, but also workforce based authentication solutions to adopt that. So I would really say Fido is the right choice for the future today. There's still this smart card based of indication stuff around, which will still be there for, for, for some time that Fido is certainly the future.
Guessing it'll be the same answer for this question. How does passwordless work if you're using multiple or shared devices?
That's again, a bit more of an explanation, but that definitely works because many people think of passwordless automatically. They think of windows. Hello, which is a very obvious way. And there you have this one-to-one relationship where you are connected to your device. And that's really where the question is coming from. How do you do it with shared devices? You have to have your password less authentication out of bend, as long as you're bound to one machine because your biometric information or your pin in the, in the worst case with windows cell is thought on the machine itself, you obviously can only log into that machine to find a solution, to have multiple users log into your machine, or you log into multiple machines. Passwordless you have to have an out of bound device. And this could be a mobile device like this. This could be a security key. I think the guys from UBI key around, so things like this is actually helping you perform exactly that.
And this is a question from one of my colleagues, some prominent attacks lately have bypassed MFA. Oh yeah. How easy is it to do that and can such a tax be prevented with passwordless authentication?
Okay. I think we have to answer in two different or in two different ways because there's no direct relationship between passwordless and, and getting around bypassing MFA, even passwordless solutions could be bypassed because the bypass often recently happened with those push bombing attacks. And even if, even if you're possible in a solution, but you're still getting, getting bombed with lots of push notifications. Like we all know from Google authenticator, Microsoft authenticator, but also many other authenticator solutions. What are we doing? We are at some point we're just accepting. And once we've done that we've been bypassed, the MFA didn't really help. So this is rather a question. How do you perform or how do you implement a phishing resistant MFA solution by no longer require push, but put the user, the user into the initiative to have him perform something first and not something being pushed to him where he just needs to accept. So that's nothing to do with passwords in general. That's the question? How does this authenticator solution really work and get away from push, get to a user initiated log in.
Thank you so much. And that brings us to time. You can come in. Thank you.