Hello everybody. I'm Erin perk here to talk about MFA and single sign on Fort and constrained devices. A little bit about me. I work at Okta. I do education and training on OAuth and opend connect. I have a, a book and a video course and do a lot of in person and remote workshops. But I also participate at the I ETF, which is where the OAuth spec is actually developed. And that is where, where all the specs are written. And there's a really strong community of people who are working on solving all those problems. So title of this talk is full of a lot of acronyms and jargon. So let's go through and talk about what these actually mean. So MFA, SSO IOT, all these, all these terms, I'm sure you're familiar with some of them, maybe even most of them, but MFA is the idea of multifactor authentication.
And that's just the whole idea of using more than one thing, which the one thing is usually a password using more than one thing in order to log in for better security. And we're gonna get into each of these in more detail throughout this session, SSO is single sign on, and that's the idea of using the same account to log into multiple places. IOT of course, is internet of things. So that would be smart. Home automation, smart lights, which is bulbs, voice assistance, whatever things that don't, that aren't traditional computers, but that are online. And then constrained devices is the idea of something that is limited in either its display or its input capabilities. So again, you think of a computer, which with a nice large screen and a smartphone with a, a screen that can show you all sorts of information. And both of those have pretty okay input capabilities.
A keyboard on a computer is pretty easy to use a keyboard on a phone is pretty easy to use what happens when you're on a device that doesn't have those things like a voice assistant or a, the example earlier of the, the machine that you're running the treadmill machine with a screen on it. Right? So we're gonna go through these one by one to talk about, talk more about these. So multifactor authentication, you might be familiar with this idea from using forms like this of a UV key, where you plug in a security key, and that gives you an additional thing that you need in order to get into an account. This can also take the form of these codes that you have to enter, and you may get these codes, any number of different ways, either through the, a Google authenticator app or from a push notification into your Mac or over SMS.
These are all part of the same family, but they do have a lot of different properties. But the whole point is that instead of, instead of just a password, if you, if you only use a password to log in, there's a lot of problems with that. So why, why one example of a problem with just password based authentication is people do reuse passwords, even though we tell them not to. And even if people aren't using, especially if people aren't using a password manager, right, what happens if you reuse, reuse passwords? Well, your service that you think of as the, the one you care about might be perfectly secure. And, and there's no problem there, but what happens if you've reused it on another service that maybe had less security and their password database got stolen, and then the attackers would take all those passwords and then just start trying them random services.
And eventually they will find some that will let them in. And this is not a theoretical problem. This has happened quite a lot. So the good news is that adding multifactor authentication to this means that a stolen password alone is not enough to actually break into a service, which is great. So that's a step in the right direction. Now, what it means is if an attacker did have the password for this account and they tried to log in, they would then see a challenge that says, oh, that's now go, you know, enter this code that we've sent to, to your phone number. And then that stops the tech cuz they don't have that phone number. So they can't log. It sounds great, but it turns out we're not quite done with that. This might also take other forms. So, you know, logging into an iPhone app and then you would get like a push, a push notification possibly on the same device. And even though you may think, oh, but that's not two different devices. Where, why is this considered multifactor? Well, the point is that if somebody did have your password and try to log in from a different device, your, your phone would still get the push notification. So it still stops that attack.
But some methods, some types of MFA are actually significantly better than others. And there's some pretty serious problems with certain types of these. Some of them are fishable. What I mean by this is if someone is trying to trick you into logging into a thing that you think is real. Some of these MFA methods, you can still be tricked into giving up the MFA codes and letting the attacker in, which is a different problem than stealing a password and just trying to log into something random. So essentially anytime that you've asked the user to take something and manually copy it somewhere else, or just click a button to allow the login to happen, they can be tricked into doing that unintentionally. The goodness is there are some methods of MFA that can't be tricked into into doing this. And these are the, the family of these is web often or the Fido world of all based on these hardware keys, to give you an idea of how, what this might look like as an attack, let's say you get an email that looks like this.
And by the way, this is actually really what it looks like when you get an email, when somebody shares an iCloud folder with you, I think they could probably work on the design a little bit. This doesn't look terribly trustworthy to begin with, but it is a real apple email. There is one difference. If you can spot it, that hyphen should have been a dot. So the whole idea with this is, you know, the, the, the attacker would register this domain number, reply-icloud.com, which looks very close to the real one and send you this email, which they can copy from the, a real template they get. And you're like, cool. That looks like an important document. I should click that and open it. And now you're expecting to have to log into your iCloud drive. And that's where this whole thing starts. If you're expecting to log in and you see a prompt that is, that looks like this, you would then say, yes, I'm trying to log in.
So I will give my password to this. And this is a fake website on that fake domain. And then you're like, cool, well, I've got MFA on my account. So the problem solved, right? Well, not exactly because if you are trying to log in and then you get a prompt like this on all your phones, you would then input that code into the attacker's website. Meanwhile, what the attacker has done is once you give your password in, they go and take your password and send it to the real apple website, wait for you to enter your MFA code, give the MFA code to the real apple website. And now they're in. So that's the problem with the fishable MFA methods, which is anytime that you're asking users to type one thing from, from a screen into another place, the good news is there are solutions to this, which is the whole web end world.
The reason those are not fishable is because of the way they work, which is that they're actually tied to a domain. The credential that gets generated is actually tied to the domain that you're logging into. So you, you stick the UBI key in the computer, you tap it. And the credential is generated for google.com, which means if there's two different domains, the credential would look different. So the same UBI key or the same thumbprint would now appear different to the two different websites, which means even if you did fall for the phishing attack and give your password to the fake website, the credential that it gets from that hardware will be different and they can't reuse it. So that's really good. Now we've created a new problem because a lot of companies actually run services across a bunch of different domains for themselves that are considered first party, right?
Google has a bunch of different websites that you can log into using your Google account. So if you want to add MFA to your Google account, and they've got a bunch of different websites and you were to try to use a hardware authenticator, you would have to essentially enroll it in every different website, right? Which doesn't make a lot of sense. So instead, what we want to do is have only one domain where the actual login happens and that's where the credential is tied to. And then somehow create a way for all these different websites to use the same website to log in. That's where we're getting into the single sign on idea.
So as things, when things start out simple and you just have one application, you don't really have this problem, right? You have one app, a user types in the password they log in. Everything's great. You can add MFA to that. Any number of ways and things are pretty simple. As soon as you start publishing multiple apps, that's when things to start, start getting a little bit complicated. So you could put password prompts in all of the different apps and ask users to enter their password. Every time they log into one of your other apps, it's not a great user experience. And then we start getting into the challenges of, of actually adding MFH to that.
An an analogy I like to use is if you were to go check into a hotel and they give you a key chain full of five different keys, it's not a great user experience, right? One key opens the front door of the hotel. One key opens your room. One opens the gym, whatever that's not super great, and that's not what we do in practice. Most of the time, instead you go to the hotel, you go to the front desk, they give you a hotel key one card that lets you access all of the resources in the hotel. That one key gives you access to all the different things that you might need throughout your stay at the hotel. And it's also time limited and it can be deactivated after your stay. So this is what we want to do with, with the online world as well.
And the good news is this problem has already been solved. So when you go to Gmail, for example, you don't actually enter your Google password on the Gmail website. Instead Gmail sends you to Google's OAuth server accounts like google.com. That's where you log in. Then you type in your password and then you get sent back to Gmail and you're logged in. And the nice thing about this is it works the same, whether you're on Gmail or YouTube or whatever, but now if you want to add MFA to this Gmail, doesn't really need to care. Gmail just says, go to the O a server. The OS server says, what's your email? What's your password? Oh, now we need you to do an MFA prompt. And that's where you do the MFA. And now you can use a strong authenticator tied to accounts on google.com to actually log in here in a way that uses MFA, securely, that can't be fished.
And then you get sent back to Gmail. So what's the key thing that's happening here? Well, all of the complexity of managing MFA and managing account security is all over on this side at the OWA server. So no matter how many apps Google has, those apps don't need to care about anymore. So on YouTube, same, same idea, right? YouTube just says, okay, go over there. They'll deal with it over there. And eventually you get sent back to YouTube and you're logged in with the same using the same Google account. So now bringing this back into the world of IOT, the reason this is relevant is because what we've been able to do with that whole mechanism is offload the complexity from the device. And in this case, the device we've been talking about was the Gmail app or the YouTube app. And we've actually moved all the complexity of the process of logging in over onto the oat server.
So T constrained devices, I'm gonna put these both in one bucket for the purpose of this discussion, for example, an apple TV or, you know, Amazon Roku or whatever, that kind of device, where there might be a big screen. Once you plug it into a TV, but the keyboard there's no keyboard. And the, the way that you enter text on the screen is a little bit clunky. It could also be other types of devices like a kiosk somewhere or a, or that, that stationary bike or a treadmill or something, or these little Harbor video encoders. I think they have one of those in the back somewhere. And these are all devices that have a lot of capabilities themselves and can do a lot of things and they have an internet connection, but the screen is limited or there is no way to enter data.
So first of all, why can't we just use regular password off on these? You sometimes sort of can cuz you can put up like an onscreen keyboard sometimes or with a little joystick, scroll through a set of characters to enter your password one by one, which is just really awkward. The on an apple TV, for example, you might see a prompt like this, which is asking to enter your password for your apple ID. And this is frankly a terrible idea and a terrible user experience because what you're doing is you're sitting there in front of an entire room of people typing out your password extremely slowly letter by letter or my favorite one, hold this to spell, like, what are you gonna do? Like spell your password with your yeah. And then like imagine doing that with a voice assistant where there isn't even any interface you can interact with other than speaking at it, are you gonna say your password out loud?
Like no. So we need some other solution for this. You might already be familiar with the solution cuz it turns out this is actually very widely deployed. And this is what, what ends up happening is when you want to go log in on one of these devices, the device shows you two pieces of information. There's really only two relevant pieces of information here, a URL and a code. And it might look different depending on the app you're logging into, but it's always those two things. So on devices that don't have a full, huge display, you can still do this, right? As long as you have the ability to show just a couple of letters on a screen, you can, you can pull this off and you can imagine with a voice assistant, it could actually read the URL out loud. That's maybe not the best experience, but it's certainly possible.
The point here is that you go visit that URL on some other device. Like you take your phone out, you type in that, that URL. And then it prompts you to enter that code. Once you enter that code, now you start a login flow that you're familiar with, that you've done over and over again on this device, you sign in type in your email, you choose your, your YouTube account. You say, yes, I want this device to, to be able to upload videos or whatever. And then on that device it says, cool, you're done. There's no nothing else to do on your phone. You put your phone away. And meanwhile, now that device you've logged into has the tokens it needs in order to actually do the work. So, okay. What about, well, the, the nice thing about the way this works is there does not need to be a link between the two devices.
There does not need to be communications channel. We've got this device talking to, to the OWA server. You've started, you've linked this device by talking to the OWA server, entering that code. And the two devices don't need to talk to each other. It turns out that's actually both good and bad. The nice thing is that it can work on a lot of different devices, but it does introduce a new problem. So, okay. First let's talk about MFA and it turns out this is actually a very quick discussion because the, the answer to, how do we add MFA now is, well, once you've got this whole infrastructure in place, there's nothing to it. You, you start by visiting that URL on your phone, you type in the code, and then once you log in and enter your password, now you get the MFA prompt on your phone, where you normally get it and you can use the strong authenticators.
You can use web authentic touch ID, push notification, whatever you want to to do on for your MFA. You can do that because it's on your phone that already has it set up. And then again, the phone just says, yeah, you've connected. And now the device has the tokens. This is the ice flow. This is a link that will give you more information about how it works and how to actually use it and links out to code and stuff. This is the goodness is this is very well supported and widely deployed. And I think we saw a, a demonstration or more detailed diagram earlier in this room about this as well. But I mentioned there's still one problem left here, which is that back to our idea of fishing, the problem is because there isn't a link between the two devices, the TV and your phone that now opens up a new possibility of fishing.
Because remember, like I said, at the beginning, anytime you've asked a user to take something and enter it somewhere else, they can be tricked into doing that. And there's a couple of pretty sneaky things you can ask of people to get them to either type a code into their phone during that kind of login screen that might get an attacker logged in on the remote device or vice versa of tricking people into authenticating their TV as the attacker's account, both of which can be bad for very different reasons. So what we actually need to do is to solve that as well. We need some way to take these non fishable MFA methods and apply them to that device. And this is kind of where the story is. I don't wanna say ends, but this brings us up to the current day. This is what is currently being solved.
Now, there isn't a solid solution for this problem yet there's a couple of experiments being done by different companies who have this problem and have deployments of these kinds of devices. And a lot of this is now being talked about in the OAuth working group. In fact, even just last week at, at the OAuth security workshop in trhe, this came up again as this is a problem and we need to solve this. So the, the solution is gonna involve something like actually taking that, establishing a link between the phone and the TV of some sort, something that can sort of guarantee physical presence that way you at least can't be tricked into authorizing an attackers device that might be in another country. But that is what I wanna share with you today. Thank you all very much. And you can learn more about OAuth and these kinds of things at these two, two links, OAuth WTF link to my book, and course, and OAuth net is the community website of OAuth. So thank you very much. Thanks,
Aaron. Really appreciate that.
