The evolution of user logins

Next. All right. Thank you all for coming out. We made it through Thursday. Is everybody like totally wiped out tired? I am, I'm gonna have to breathe through this, get enough energy to keep going.

All right. So I'm gonna be talking for about 20 minutes about logins, right? The history of logins. Uh and we're gonna go way back in a time machine and then we'll come all the way to the, the modern era.

So first thing if first is logins are now extremely complicated and so we're gonna go and see what they used to be super simple and then we're gonna look at the full stack complexity of logins these days.

All right. So take a time machine. I'd used web uh the archive and I went back and I grabbed Yahoo from about 2000, right? I didn't, I was gonna do Amazon, but you know, I didn't think I would be accepted for the speech.

All right. So this is their login page. This is what the code looks like. So I just didn't inspect and you know, it's a standard form, right? It's got a form, it's a post, it's got some javascript. Not really sure what it's doing. Can't really get at the javascript anymore. So we kind of have to guess. And then it's got a login and a password.

All right. So this is my guess. So. Obviously there's no TLS. Right. That's bad. We're probably using server site sessions. It's my guess just, you know, noting what they're doing, they have an on submit handler. So I'm guessing they're doing something with the password before they send it across the wire. They may have been sending plain text passwords across the wire. I'm not sure. But my guess is they weren't, they were a little bit smarter than that.

Uh they have an open redirection if anybody knows about those attacks. So they just, you can go anywhere, you want, you could just put your website in there and then it would send the user after they logged back to your website instead of Yahoo. So that's not good.

Um and then they probably were storing the hash here, right? And that was sent over there in the in the post. So it's, you know, it's a naive approach, but it works.

Ok. So here's what we were looking at right back in early two thousands nineties, we had two layers, not much going on in between. We had the browser, Netscape, you know, whatever Mozilla kinda. And then we had the server send data across, you get logged in and then the server replies with more html so pretty straightforward.

Ok. What does it look like today? So it's a lot more complex, right? We've added all these extra layers and all these things that we need to take care of and secure. So you start at the top and we have the network. So as the data is flying back across the network, we now are way more connected than we used to be. And so at every step of that exchange, you have to be analyzing the data, analyzing the packets, see what's happening on the network and it's open, right? The internet. So anybody can come into your network, you have the infrastructure, right?

So now we're looking at the servers or the virtualized, you know, virtualized servers or the containers or whatever and we have to secure those we did that back then. But less. So once you get into uh passes a firewall, a lot of servers are just open and all the communications between them were open as well. So we're not doing that anymore. You got to consider the applications and then you have to consider how applications are talking to each other via the API s. So you have to secure all of that.

You still have to think about the browser, you know, we're still using browsers for pretty much everything and then we have to consider our users. So let's start diving into each one of these and talk a little bit about some of the constraints and issues that come up.

All right. So the network, right, obviously, we're using TLS, that's just like guaranteed. Like if you're not using TLS, stop what you're doing, get on your laptop, implement TLS right now, HSTS. So what that does is that enforces TLS, right? It basically specifies that a domain has to be TLS in order for you to access it in a browser. So you have to implement that as well. That's now a requirement.

We also have firewalls at every step of in every layer. We're hitting a firewall and that firewall is protecting ingress and egress from a network to back to the browser or back into an internal network. And so we're setting these firewalls up at each level, we have load balancers, they're obviously doing switching.

We have a lot of rate limiting that has to incur, right? Because people are attacking our boxes every day. We're getting thousands of requests from god knows what country. So we have to handle that. We have to globally distribute this right? We don't want everything going through a really slow line all the way into our servers. We have to basically start routing traffic in the most, you know, the quickest pattern to get to down to our servers. So we have to consider global distribution as well.

A WAF every packet that comes in needs to be inspected. We have to determine what URL are they hitting? Does it look malicious or are they attacking a PHP site and some known vulnerability? Right, because they can start asking our servers for information, they can see what we're running and then they can start attacking it. And so we have to put a, a WAF in front of that in order to protect our servers.

DDoS. Like this is actually a really challenging problem to solve. We have to look at heuristics of how traffic's coming in from different locations and determine whether or not it's a botnet that's attacking our servers trying to crash our servers, credential stuffing.

We have to watch as they're going and downloading lists of breached credentials and putting them in the login forms. They might be doing it slowly and they might be doing it from 10,000 IP addresses. But we have to watch for that and we have to know what's happening so we can block it, right?

So this is just all annoyance, right? This is just, there's people out there that just love to annoy the crap out of us and we have to protect our servers and our applications from it.

All right. So now we go down one layer and now we're on the infrastructure. So kernel patching, I mean, you know, their kernels have vulnerabilities and so we're constantly patching kernels, you have to keep them up to date. Usually the cadence is um you know, multiple times per month. So that's a pain in the butt.

Ah, you have to harden your OS, right? You can't, you want to run as little on your OS as humanly possible. If you're in Docker, you have a little bit of benefit, but you still have the host machine which you have to harden, you have to do least privilege every service on that machine should not be running as root bad. It should be running as the least privileged user that it needs to in order to get to do what it needs to do.

Zero, trust, trust nobody that's coming to your server, right? SMS email. So the list goes on and on, right? And it just gets more and more complicated. We have to look at all of these things when we're considering our infrastructure because this is like table stakes now our application.

So now how do we actually implement login? We're finally at login, right? And we've taken all the other stuff out. Well, we got to think about OpenID Connect, SAML I don't know anybody who loves SAML I don't I, but we have to think about all these things like how is our application going to be sending the tokens? How do our tokens get issued? What type of tokens are they? Are they encrypted? Are they signed? Do we validate them? How do we deal with assertions?

So like can this user actually access this resource if they click that button? Are they allowed to do it, right? What happens when their tokens expire? How do we refresh those tokens? What happens if their refresh token gets stolen really bad? Right. So we have to protect against all these attacks. There's one time use refresh tokens, there's multi use refresh tokens. So you get it right?

And then we have to layer a bunch of stuff on top of that, like biometrics, you'd never want to put biometric stuff on the wire. It should always be on device. So now as a developer, you have to think about that and you have to figure out how you're going to use biometrics to prove someone's identity without shipping the biometrics across the wire.

And our APIs right? So now we're, we're, our application is gonna call services. And so we have to think about API gateways. We have yet more tokens machine to machine tokens usually, right? So we want these machines to authenticate themselves and protect from malicious attacks at the API level.

What about grant? So like as a user clicks a button, it might call one service that calls another service that calls another service, right? This is called the nested chain of authorization. How do we know that the user that did that has the permissions to call each of those services in turn. So these are really complicated.

So as the rise of microservices and all these, you know, containers are spun up, we have to figure out how to protect them browsers. So cookies are dying, right? No more. Third party cookies, very few second party cookies. So everybody's moving to first party cookies which means it's under your domain and under your control.

So now you have to make sure that your cookies are consistent across domains. If your application is traversing domains, another pain in the butt, same site attacks, you have cross site scripting attacks, CORS is now a requirement. So you can't ride an app without thinking about CORS.

All right, you have to start thinking about FIDO. So WebAuthn and how do you get FIDO? And how do you work with the browser to get, unlock the vault and the secure enclave on the actual machine that might be storing tokens or it might be storing that biometric information that identifies that user. Ok?

And then finally your users, right? So bad passwords, like that's the simplest thing like using password is password, uh multi factor authentication. I'll talk about like how much of a pain in that, but that is to implement here in a second. But it's hard, right? The reason we do that is because people use crappy passwords. So you have to force them to do something better because now it's too easy to attack their accounts because they have crappy passwords, right?

Uh botnets. You know, again, we have credential stuffing. It's really easy to go download breach data sets. There's, you know, a few terabytes of data that from all the attacks on Yahoo and you know, the credit reporting agencies and Octa. So lots of stolen credentials out there. Easy to get your hands on and easy to go use them to log into websites.

Social hacks, your, your customer service reps now have to protect themselves against people who just dial in and pretend to be someone else. So that's a pain in the butt. And of course, you know, the ones that we all know and love, we all become it for our moms and dads and they don't know how to use computers. So it's their passwords are inherently horrible. Here is the remaining formatted transcript:

So this is now a worldwide problem. Right? Most of the world's population doesn't have access to email. So we have to think about identity in new ways and through this entire stack, the, the, the 50 things that we've listed out. We, we have to think about this as a global problem. And how are we logging people in from different regions of the world?

Governments are also getting involved. So US is kind of dabbling in it with Gov ID, Europe has theirs. So we're seeing that more and more even states are starting to do state IDs, right? You can now, like in Colorado, you can now store your ID encrypted on your phone. So when you get pulled over whatever you can show your ID on your phone, right. That's another identity problem that we have to deal with, you have to log into that device to unlock your ID to show it.

Yeah. Ok. So I'm gonna walk really through a really cool hack that happened to me through an MFA exploit that my bank allowed. It's pretty cool. So, so, so this is how it went hacker calls up CS. The CSR pretends to be me. I, I think they may have called like two or three times to get a, you know, the CSR that would do this for them, but the CSR verified their identity through really weak checks.

Like what street did you live on when you were a kid? Uh what's your mother's maiden name? Right? Like really stupid checks. The CSR verified them and then proceeded to change their email address, right? And so depending on what bank you're with email addresses are one of the forms of MFA.

Then the hacker goes and does a forgot password on the newly changed email address, which is theirs, gets the forgot password link, clicks it changes the password. So now they have access to my account. And when they hit the MFA screen the email that the CSR changed is the one that they used for MFA so by changing the email on the account, they could bypass MFA right?

And then they stole uh about uh you know, 300,000 points or so from my account and they knew to do this because points did not require a secondary verification because they're just points, right? And so the credit card companies just move points around. Well, those are cash.

So I called up my bank and I explained this to them and I said, you know, the breakdown was right here when you change the email, it should not have changed the MFA. MFA and email need to be separated. If you set up an MFA with one email and you change your account email, it should not change your MFA email, right? That was the breakdown.

So a very simple situation like this becomes very complicated. And so this is a, you know, a huge bank. It's probably the largest, one of the largest banks in the United States and their security is weak at best, right? It's very easy to exploit this stuff.

Yes. So what do we have now? Right? Here's the issue security is now a multidiscipline problem with massive complexity. It requires network engineers. You know, you have to think about biometrics and MFA you have to have your devices locked down, you have to think about authorization at every level. You have to think about nested chains of responsibility.

So no one single engineer can do all of this. This is way too big of a problem for one person to solve. So the entire team has to be involved in this now and we have to sit down and think about all these things before we ship our login page and that's just for login.

So when you're thinking about your next project, building out your app, considering what you're gonna, what you're gonna do for your login pages, consider all of those.

So that's it for me. Thank you. If anybody has any questions, got a couple of minutes, so feel free to fire them off. You can also find me on Twitter or on LinkedIn. Feel free to connect with me. I'm an open connector. So thank you.