Root Causes 215: Passwordless Authentication and Legacy Systems

Hosted by

Fellow

Original broadcast date

April 8, 2022

Organizations seeking to use passwordless authentication frequently must deal with legacy systems that cannot support this scheme. In this episode we explain why that occurs and detail the steps organizations can take to mitigate the effect of legacy systems.

Podcast transcript

Lightly edited for flow and brevity.

TCTim CallanThis is going to be the latest in our series of explorations of the concept of passwordless authentication. In this case, we've touched on this before, but we want to focus and deep dive on the concept of passwordless and legacy environments and how do they work together?

Jason SorokoI think this is an important topic because a lot of people when they take a look at the marketing term passwordless, they sometimes might ask themselves, well, does this apply to every single environment that I have? The really harsh answer to that is probably not, unless you're some sort of cloud native organization or you’re very modern enterprise, you may have legacy environments that might not be applicable for putting a layer of password authentication or reconfiguring so that you can use passwordless authentication.

TCTim CallanJust quickly, what would the reasons for that be? Like why would it be that my legacy environments would not be able to become truly passwordless?

Jason SorokoLet's go as far back as saying mainframe systems. Mainframe systems. You're not going to be turning that into a cloud system overnight. And in fact, what I mean is, you some of you on this podcast are gonna say, Jay, you're totally wrong. I have a cloud interface to my main, my old mainframe. That's great. But the problem is, there's still a password underneath that.

That's the argument I'm trying to make. And let's now move to what probably what's a more, even a more common scenario, which is, Tim, you and I lived through, we are just so old, so old, that you and I remember monolithic enterprise systems that typically were installed in big computers in the server room and they were very much like a mainframe in that you can't change them. Like, the only way in was to network to them and to authenticate through username and password and there's no configurability because the people who design that system are probably either retired, or in different stages of their life and there's just no way to be able to take an old human resources system or a finance system back from the mid 90s, and turn it into a fancy-dancy strong authentication type of system. There's only one way in and that's your username and password.

TCTim CallanIt would be equivalent to just creating a new one from scratch. There's, you're talking about a scenario where this code isn't really understood, it's not probably well-documented, it may be the source code isn't available for some of it and you literally would have to have a project to rebuild this whole thing from scratch and while that might be an admirable idea, it's also easy to see how it's not something that's ever actually going to make the roadmap and get delivered.

Jason SorokoExactly right, Tim. And so what we're going to be talking about here is, in this podcast, what are some of the things that you can do? What are some of the gotchas related to some of the things that you can do? Because all is not lost. Even though you have you have to support these legacy systems, I think there's still some things that are available to you. Let's start with the one, Tim, that might not add a ton of security. It adds some. There's definitely some. But I think really what this is about is modernizing the user experience of trying to log into these legacy systems.

I'm gonna categorize this and I think we spoke about this on a previous podcast. This is about essentially what is a password manager on steroids, which is going to be an agent on your employee’s laptops, their workstations, perhaps even their Android or iOS devices, which says, alright, you want to log into ancient finance system X. What you're going to have to do then is go through a biometric and then perhaps there's a key pair associated with that and then what I'm going to do as your agent, is I'm going to log in with a username and password underneath, but you don't have to key in that username and password.

That's essentially what's happening. I'd like to consider that a password manager on steroids because it's not typically the password manager that you all know and love which is you open up your password manager and about to log in to something, I can copy and paste the password and I can paste the password into whatever website or application that I'm trying to log into. This is not what we're referring to. This is something that fully abstracts away the username and password authentication experience away from the user, which is a positive experience. And so what's the security aspect to this, Tim? The security aspect is alright, there's perhaps less chance of social engineering.

TCTim CallanI was gonna say the security benefit is more than zero. Because there are many aspects of guessable passwords are removed from the equation, repeat use of passwords is removed from the equation, social engineering attacks are more or less removed from the equation. Those are a lot of the ways that passwords fail.

Jason Soroko100%. Hallelujah. Anytime we reduce username and passwords at all we are improving security to some extent and in this case, I think the big one is social engineering, let's talk about that finance user for a moment. What happens if they're being phished and they've been sent an email with a link that looks an awful lot like one of the other systems that they may use? Hey, enter in your username and password? What happens if they never use a username and password for said system anymore? Fantastic. They might just get confused and go? I don't understand. That's not how I log in. Therefore, that's a really positive thing. However, and this is the big however, what happens if the bad guys, the attackers, have actually gotten into the enterprise through some other means, which is entirely possible, and are watching the network. They're watching those interactions on the network and they are able to basically look at when this person is logging in the username and password that corresponds to them is x, especially if the system is old enough, perhaps the system can only accept those commands in clear text.

TCTim CallanYou've gotten to this right, when I think about our Episode 177, where we first sort of define what is passwordless. In that case, I think you explained very clearly, the distinction between apparently passwordless and actually passwordless. Yes, it's great not to have to remember and type in a password. Yes, it's great that these kinds of attacks get removed but a lot of people make the false assumption at that point to say, ah-ha, this is passwordless. But it's not, because that vulnerability you just described is still present as long as any kind of shared secret is being used.

Jason SorokoSo Tim, what's incredibly important to what you just said, is, look, those kinds of username and password masking systems - what I like to call an abstraction layer. Those types of systems might be perfect for you. Might be perfect for you. They will increase security. They will definitely increase the user experience but what you have to keep in mind is what you just said - which is there are there are still ways the bad guy can get in.

TCTim CallanJust be clear on what you're getting and don't think you're getting more than you are and what you're getting is great, but don't think you're getting more than you are. I think that's the point.

Jason SorokoEspecially in systems where the password itself is going to be in clear text somewhere on your network, when the login actually occurs. Like become aware of this. If you're going to be implementing the system, these are simple checkboxes that you need to understand. Is the legacy system so old that there's no other way to communicate to it except through a clear text command? And if so, even if it's not, and there's some other means of communicating, is there some way of the bad guy being able to underneath that abstraction layer, being able to issue some sort of replay attack once that attacker understands how to do the synthesized authentication, which is essentially a username and password.

TCTim CallanIf there's some kind of hashed information that's being passed that is consistent and I could capture that hash, I don't need to be able to unhash it, I just need to know when to use it and represent it perfectly.

Jason SorokoYou've got it, Tim. And these are the kinds of assumptions that I don't think people make enough. I think they buy a tool, think it's good enough and there you go. It's definitely going to give you benefits, but I think your homework isn't over is all I'm saying.

TCTim CallanAbsolutely. So speaking of buying tools, this is the kind of thing that can be accomplished through my popular third party single sign-on service. We could rattle off the names of a number of those, or is this the kind of thing that would need to be custom built?

Jason SorokoI definitely think, Tim, there are some off the shelf single sign-on systems for legacy systems that can work with those. For legacy systems that cannot, there's an entirely different class of abstraction layer, which you might think of like a single sign-on system, but think of it more, like I said earlier, it's an abstraction layer so that there's a stronger form of authentication on the surface at the user level, which then triggers a username and password login underneath. Ttherefore, it's not, it's not like traditional single sign-on it's customized to the point of look, I as an abstraction layer can handle extremely basic authentications like the old days just filling in a form of a username and a password. Almost think of it, Tim, like - oh my goodness, people are gonna hate me for using this analogy - almost think of it like RPA underneath strong authentication. By the way, that's not really what's happening. That's an analogy. The reason why the analogy kind of works is the username and password is being entered by a robot. A bit of code. And what triggers that agent, that bot to do its authentication underneath, is actually a user event, which is a stronger form of authentication. That is why I call it an abstraction layer. The user is invoking something, and then some bit of code is being automated and executed underneath.

TCTim CallanI get that. I think that's clear. That's a clear, cogent, and I'd say, pretty thorough explanation of one of the things I can do to increase my security profile, and also just make people's lives a lot better with these old legacy systems. Are there other measures people can take to help overcome the shortcomings of these legacy systems in this regard?

Jason SorokoI think generally, overall, once you have identified legacy systems that cannot utilize more modern forms of authentication, whether that's to put MFA or true passwordless, I think what's important is taking inventory of those legacy systems (a) is vital and important. First of all, if you're not doing that, you're really up the creek.

But number two, (b) I think it's important to then ask yourself, can I isolate these systems? Because what used to be very common, Tim, is, you know that HR system, that legacy finance system, were just sitting in the server room and my ability to address those servers was, hey, if I'm on the corporate network, I can probably address those servers. In other words, I can start issuing an authentication command to those servers, as long as I have access to the enterprise network. Very flat networks. Those systems are right at the surface of that flatness. So I think my way of thinking about it is get your networking people to consider is there a way to isolate those systems? By isolating, I mean, alright, should I be able or should I, should I be forced to authenticate to something else before I get to that specific server, and I use very generic terms there, Tim, because there's a lot of ways of doing that.

Depending on what the server or application is, you may or may not be able to do certain kinds of things. Or it may be so onerous to the user, that you would choose not to do that. All I'm saying is this - if you put that vulnerable system to a different segment of the network, and force stronger authentication to that portion of the network, you might be adding a layer of security that's very useful. In other words, the problem of the flat network is a major issue in why the bad guy is able to get into that system so easily. In other words, make it harder and use stronger forms of authentication in a different way. I think that one of the methodologies that might be quite common is hey, like, in other words, put it on its own network and VPN into that network with a strong form of authentication. That may be a way of doing that.

TCTim CallanA lot of these ideas are probably good ideas anyway, or good ideas in a lot of circumstances. Like regardless of trying to solve this one legacy password problem now you're getting into the general idea of break down the flat network. Isolate and compartmentalize and make lateral movement difficult, it makes your overall security profile better. So this is the kind of thing that a lot of organizations are trying to work through anyway. They are getting knowledge, they're obtaining tools, they're putting systems and processes together to create that isolation. Why don't you take that knowledge you have and those tools you're buying and the work you're doing, and try to apply it in this specific situation.

Jason SorokoTim, everything you just said is an enormous consideration that needs to be balanced with, well, what is the risk of this system? Is it a core finance system that if bad guys were to get into, I'm hosed? Or is this some legacy system that performs a singular task that man, I don't know, there's no PII in there. You've got to measure the risk.

TCTim CallanIf the employees can't request vacation for a little while, maybe, maybe, maybe we'll all get through somehow. If on the other hand, this is the basic thing that makes my basic business run or this is what moves the money between bank accounts, or this is where all the PII is sitting for everybody, then you'd consider that risk to be considerably higher.

Jason SorokoThat's exactly right, Tim. Part of what makes the isolation idea hard is a lot of these legacy systems have a database component, which is used as a, hey, this is the single source of truth for a lot of my other modern systems.

Therefore, I cannot isolate this system. That's the worst case scenario, to me. From the real challenge of if you're a cybersecurity specific employee at this organization, you've probably had very harsh conversations with the people whose lives are dedicated to keeping these systems up and running and available and just interoperable and, these people are, they don't, they absolutely do not want to be considered second class citizens and what they're doing is very important, but you, as the cybersecurity professional, you've probably now no longer have gray hair, you have no hair, because you realize just how vulnerable this system is.

TCTim CallanSo one of the things that we've talked about also in previous episodes is that oftentimes, if something that old, for want of a better word, is still in operation, there's a reason for that. It's, frequently it's because it's foundational, and other stuff is built on top of it and you can't just pull out the foundation or things stop working. And that can pose a particular challenge for a number of reasons. Like one of the things you had, you have to have availability and connectivity in a lot of ways to a lot of systems. Another one is, that's where the core stuff is. You can't just swap it out, because it is this, this starting point for so much else that you've built over the years or the decades. So that does pose a particularly serious risk to consider.

Jason SorokoSo Tim, let's get into what I think are the lesser solutions, but I think no less important to consider and keep in mind. You're living in this world where you have a foundational legacy system that you cannot isolate in a network. You can't throw some modern authentication on top of it. You can't really do much at all. Ok, well, Tim, if you listen to all 200+ podcasts of our series you might get the impression I'm not the biggest fan in the world of monitoring tools.

And that's because I can do a whole podcast about how they have failed, how they have been just bypassed, and frankly, they're problematic. However, however - I'm resisting the urge to go through examples right now. Oh, by the way, did you know that Okta, that third party that got hacked recently, that was in the news and we did a podcast on that, their monitoring system, which I believe was FireEye, was merely turned off by the attacker. So there you go. There’s my example. I scratched the itch. I'm good now, Tim. I'm good.

What I am saying here, Tim, is maybe this is enter stage right monitoring systems. In other words, if you have a legacy system that has very weak authentication, and you cannot isolate it on a network, then that's your ideal scenario for ok, I'm going to have an extremely focused monitoring system, because that legacy system probably is the ideal monitoring system use case which means, Tim, it has very, very limited usability. In other words, very few people log into it at very specific times in very specific contexts. Well, guess what? That's the perfect world for a monitoring system because you can apply those rules and if you happen to see any of those rules being broken or a context is not right, well, that monitoring system can flag that to you. Of course, you end up with the risk of false positives and all the reasons why monitoring systems to me are quite problematic but they can be an important layer for a system like that.

TCTim CallanOne of the things we also touch on a lot on this podcast is, don't confuse imperfection for lack of benefit. So we can discuss all the ways that monitoring is an imperfect solution. However, if your choice is monitoring or nothing, you may feel that monitoring is a very smart layer to put on, and can do you a lot of good and can reduce your risk profile in a meaningful way where it's worth your while, even if it can't take it all the way to zero.

Jason SorokoTim, you're exactly, exactly right. Let me throw one more idea your way just because it's kind of a freebie here. And a fun one to talk about real quickly before we end this podcast. And that is to actually throw out Canary credentials.

You might leave around on a file system somewhere, somewhere where if a bad guy got this file, you're already hosed. But if you were to say, call the file, something like, I don't know, passwords list.txt, and put in, Joe Admin and a password to a finance system, and name the finance system, whatever it is.

TCTim CallanAnd give yourself alerts. So the instant that one of these credentials is used, and now granted, you're already owned at this point but at least you can take immediate action, rather than having one of these situations where someone sits around owning your network for 60 days before you ever discover it.

Jason SorokoI hate even throwing off that idea in a way because some blue teamer type people might say, might give me 10 good reasons why I'm an idiot even for mentioning it. But I bet you I could find another 10 blue teamers, who would say it's a great idea. So all I'm saying is, depending on your circumstance, it's just something to think about.

TCTim CallanOnce again - sorry for this - but once again, themes we keep returning to - one of these is know what you're getting. It's not necessarily right or wrong, sometimes where the wrong is, is if you overestimate or misunderstand what this technique or this tool is doing for you. So know what it is and know what it isn't and under those circumstances, it's hard to see how it's really hurting you.

Jason SorokoThat's it, Tim. That's an incredibly important message that's part of this podcast, I'm out of ideas for now, Tim. I think, for those of you who live with those systems, you have my full sympathy. I think we all do to some respect. And so therefore, just keep an eye on those old systems.

TCTim CallanIf there's something we missed, Jason and I are trivially easy to find on LinkedIn. People send me messages all the time. Why don't you reach out to one of us and tell us what we didn't discuss and maybe we'll do a follow on podcast and we'll mention those things too.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!