 All right, good afternoon everyone. My name's Peter, I'm from Catalyst and I'm here to talk about authentication security, the nuts and bolts and how to get at least a sane baseline config for a relatively vanilla Moodle with a couple of plugins. So a quick about us, Catalyst were a long time Moodle partner, service provider, where everywhere we have clients everywhere and we're across a ton of different time zones. I'm from Australia, it was a long trip, but I'm happy to be here. Here's some quick photos of our lovely team. I love showing off our global presence, it's fantastic. Cool, all right, so security, why does it matter? I hope that's relatively obvious. When we have services on the internet, they cannot be not secure, it's not an optional component of the way that a partner operates a service, like a Moodle. But the two major things that really we're looking to protect with a Moodle are the intellectual property. We've got training materials, course designs, and all of these are housed within your Moodle. And so you should take measures to protect your intellectual property. But additionally, there is personally identifiable information about your users present on the platform. Some of which is the user data, some of which is their training data, their grades, those kind of things. And these are all kind of a key target for cyber attackers to look to exfiltrate. They can be used in identity theft, whatever. And so organizations should additionally take measures to protect their learners. So the way this is typically done is to use something like an identity provider. And they're awesome. Identity providers are the gold standard for how we want to manage user identities across multiple systems, not just a Moodle. There's Active Directory, Octa, Auth0. I'm sure most folks probably have some experience with identity providers, and they should be used where possible. But sometimes it's not possible. Sometimes there are things like corporate networks. I've worked with multiple clients who have an IDP behind a corporate network that our Moodle that we host outside of their network cannot talk to. That's a challenge. Additionally, there's non-managed cohorts. If you've got open learning, self sign up, those kind of things, it's hard to put those into an identity if it's a self sign up, for example. And also organizations might not always have the maturity to have their own IDP that they sustain. They need a Moodle but they don't have a ton of other infrastructure that you can wire into. And so, where do we start to try and harden down the Moodle security so that we can at least do something quite robust? Security's hard. And anyone who's worked with security knows this. It's very difficult. But generally, a good baseline for when to trust a user is when they can provide us two things. Knowledge, something they know. But additionally, possession, something they have. Now, something you know is typically just a fancy way to describe passwords. But there's a couple of recommendations here around passwords that can help to make it a bit better. Ensure your site is using a password policy. It is on by default, but the defaults at the moment are not incredibly complex. So make sure that the policy is at least somewhat complex. You know, ramp up the characters, make it a little more interesting. Another one is ensure that check password policy on login is enabled. This means that if you change the password policy, anyone who has a weak password is forced to change it when they authenticate. And this keeps your user base in line with your password policy. Now this starts to get really interesting when you look at augmenting the policy and making it dynamic. So we've written a tool, tool password validator, which essentially augments the password policy and performs a bunch more fancy checks. The best one is that it checks against the have I been phoned breach passwords API. And so what this means is that if you're checking on login, when a user authenticates with a credential that they might have had breached, it's no longer a valid credential and they have to change it. There is a tracker to bring this one into core that's gonna land soon. MDL seven, four, six, four, four. So go vote on that one. If you do wanna see this land soon, I think it'll be a four, four if we push it. But here you can see a screenshot. I'm not sure how well that's coming through, but you can see that we've got, passwords cannot be based off a single dictionary word. There's some identifying information about Smith and John Smith that does some correlation stuff. But most importantly, that breach password check is present and working and checked on login. So the second part of kind of hardening this process is looking at the something you have. Now ownership, the concept of something you have just means that the user has to supply some information based on something that they have access to, whether that's possession, access to software, ETC. So the most common here is authenticated apps, but it can also be SMS codes, email codes, or even physical key chain tokens. Those were in vogue a decade ago. And the reason this works is because the main class of attack here that we're looking to prevent is essentially credential stuffing. This is where someone has a breach credential from service XYZ and they know a username and a password or an email and a password and they just spray that into a hundred different services hoping they get hit. Now essentially, this is a huge problem on the web. There's a quote here from Auth0 who claimed that essentially half their login traffic is credential stuffing, which is kind of crazy. But essentially by forcing the user to provide not only a credential, but a second factor, that's no longer a viable mechanism because that no longer results in access. It's commonly known as 2FA, but you can have more than one something and then you refer to that as MFA. And so basically a couple years ago, we had the need to really look at doing this in anger with a proper resilient flow. And the things that existed at the time weren't fantastic because they replaced the authentication mechanism. It was just password and TOTP and it was its own authentication plugin. But what we needed was something that sat outside of authentication that augmented the process instead of replacing it. And so we built tool MFA and essentially it does what I just said. It sits outside of the authentication flow and as soon as we see a user is actually logged in, they gave us something valid. We prevent the rest of the site being accessed until they do actions on top of that to prove their identity. So this is as Matt said earlier, coming to core from 4.3, but if you're on an older one, it is still in the plugin directory 439243. And so in addition to authenticated apps, which I mentioned earlier, there's SMS codes, email codes, hardware tokens like UB keys, which are awesome. But there's also support for things you are rather than things you have. And these are things like, what type of user are you authenticating against? Like a manual account, for example, or a SAML account. Are you an administrator? Do you have a role at the system level? And it's also extremely extensible. And so something like fingerprints is essentially just drop it in as a subplugging wrapper with the protocol implemented inside and it'll just work natively as part of the rest of the system. So here's a quick shot showing, some of the ways that it can be laid and you can set multiple factors here, each of which can contribute some amount to the flow. That's their weight there. And the ordering presents a logical way in which a user proceeds through this flow. And so they may need to present three or four pieces of ID that give a weight of 25 or 30 points each. And so this ordering shows the way that these checks are applied and the way that the authentication proceeds. Additionally, on top of that, we have a table that'll go through and it'll show you all of the different conditions that it'll actually allow for a successful authentication. So this is really useful when you're designing an authentication flow to fit multiple categories of users, potentially from an IDP or from a manual login or a third class that may exist in your system. But to get started with this, it's actually really easy. A simple baseline configuration here is essentially just having the Authenticator app turned on but additionally, setting up a grace period and so that users will have about two weeks to, well, two weeks by default to log into the system, they'll be prompted to, hey, please set up your TOTP, your Authenticator app. And once that's turned on, they'll be forced to use TOTP and after two weeks, they'll be locked out if it's not presented. There's actually a small error here. Grace period should be on top because we want that to be checked first. I made the screenshot in haste, I'm sorry. But essentially putting that all together with just a couple of plugin installs and a little bit of configuration, what we have is a relatively secure Moodle native authentication process. We have passwords that are secure, not present in a breach, and users must use an Authenticator when logging in, otherwise accesses prevent it. It's a really simple set of config but it's really powerful at being able to just set up and quickly secure a Moodle for a client who needs something small, quick, or they don't have the budget to really look at an IDP integration or we can't for the reasons discussed earlier. And basically where you go from here, well the complexities are endless. Roles, networks, auth types, they all provide a really rich configuration matrix for how you can apply some of these configs. You can strengthen password policies as far as you want to to match your organizational risk appetite. But another thing that can be done here is you should recommend that a password manager is used by your users. It's one of the most effective ways to reduce credential reuse within your organization. And Bitwarden is a fantastic option that I'd recommend anyone look at who hasn't used a password manager before. So I'll wrap up there. There's kind of too much to cover in a 15 minute because it's an extremely complex topic. But I'd love to hear some questions and if you do want to talk more about these things, come over to the catalyst booth. I'm just over there and I'm happy to talk about it. I really enjoy this. It's kind of been something I've really enjoyed working on over the last few years. Well, and there's some helpful links there to the plug-ins to have I been pwned, which is a fantastic service, as well as Bitwarden. Yeah, I've got some time for questions. Hi, I'm a school teacher and I mainly work with children and they have really a hard time remembering these complicated passwords. So do you have a hint how to enforce a password policy anyways, even if the children don't remember them from one day to the other and I have to reset the passwords all the time because that's quite annoying. Sure, so this is something that can be a difficulty, especially with people who have, well, children, let's put it up. So a password manager is a fantastic way to do it. They just live in your browser and they're relatively automated to be able to use and reuse passwords or re-enter passwords without the child actually having to remember. My Google password is 55 characters. I have no idea what it is. So it's really, really powerful to be able to just click a button and have your passwords applied given you've authenticated. That may not be a perfect solution and so in cases like this, I might even encourage that you do look at doing something like MFA with SMS codes or something like that or email codes where you can perhaps reduce the severity of one part of your authentication process while hardening another that is easier for a child to access. Easy to read a code, pop it in and move along. It's a difficult problem but I'd say in that case, you can also look to reduce the complexity of your password policy or reduce how often it needs to be changed. NIST actually, they've kind of gone back and forth on the recommendations but they recommend you don't enforce a rollover on passwords as of one of their standards and instead just enforce something relatively complex, three or four words strung together and that provides a pretty sane baseline so a child can base that off media, off a game as long as it's relatively distributed and complex enough it'll form a good enough password. So recently I read an article that Big Tech like Google, Microsoft, Apple et cetera they're now embracing some new standard which is called pass keys which you can also use no fingerprint et cetera to log in. Is that something you envision to also adopt or develop? How do you see that? So my understanding of those is they're more of a complete replacement for an authentication flow. MFA still operates as an augmentation to the existing you still have to put a password in for the most part. It's probably not something that would fit exactly into MFA unless you wanted to implement a flow where it was a password plus a pass key in which case it might make sense as an authentication factor. Either way it's not something that's currently in the plugin and I don't know where that's proceeding in core. I feel like someone like Brendan may have linked to Tracker to do so, but I'm not sure how far that's moved. Yes, okay, Matt said yes. It's moving. Oh, we've got one more question, but we're, oh, yeah, right. Get up here. Cool. Just wondering if you allow the free registration on a Moodle site, how do you stop hackers registering from your site? So, you know, if you're already using something like email verification, then at the same time, you know, they're already, I guess the best way to describe this is we're not touching the current authentication flow at all. And so the current mechanisms that exist in Moodle to stop this like email verification still apply. MFA just hits the second that Moodle says I trust this person. MFA kind of says, well, we need to do more than trust them, that's it. So the measures that currently exist are still in use. We have a situation where people are creating accounts on our system and they're confirming their email and coming on and we are developing a plugin with the CleanTalk database of spam emails and IP addresses. Cool, now that sounds interesting. You know, you can potentially make that flow more difficult, but that's not gonna stop someone who's determined. And so the better thing might be to introduce some level of trust from a known good list of internal users that you might have and apply a role based on that, you know, with various other tools.