This is a transcript of the AA07 - Identification & Authentication Failures training session. Click here to return to the OWASP Top 10 Security Vulnerabilities page.

Janez Urevc: [00:00:00] So the next topic, next topic is Identification and other Authentication failures. Um, we talked about Broken Access Control on the first day, I believe. Yeah. Um, and this is somewhat related. So, authentication is about proving who you are while access control is about um, making sure that, that one, once you've proven who you are, you have access to things that you need and should have access to. Um, so this is in a way the first step. If we look at the most notable problems that are mentioned in this category is there are improper [00:01:00] validation of certificate with host mismatch.

Uh, Improper authentication and session fixation.

So especially in proper authentication is something that is like, it's, it's a never ending story. Um, because in a way we rely on our users for, you know, we cannot control this aspect of our project in its entirety.

One of the most common problems when it comes to identification is credential stuffing which is basically buying or downloading a lot of stolen passwords and then just trying them against [00:02:00] various websites. And since people tend to use a single password across all the accounts that they have. Uh, and you know, a lot of times even pretty simple and not secure passwords.

Uh, this is a very common attack vector. Um, so what we can do personally is like just always use password manager and use use a different password for every website. Um, and not just that, I would say that we should also try to promote this idea among our users and among our friends. Um, cause there's still a lot of people that don't do that.

[00:03:00] Um, even in my own immediate family, I have people almost laughing at me and it's my randomly generated 50 characters long passwords. Um, but when you, when you have a password manager, that's easy and you've protected yourself quite well. Um, so yeah, Drupal by default has this password strength indicator. So I'm on drupal.org website, which runs Drupal obviously.

And, we can see that the, if I enter a really weak password, like can in this case the indicator would tell me that my password is weak and it would suggest things that I can do in order to improve this password. Um, [00:04:00] and this is there by default on or all Drupal installations, but it would still not enforce any of those rules.

It's just a recommendation. Um, then we have a project that's called Password Policy.

And this project builds on top of that and it lets us enforce these rules and it also it also, you know, adds other types of constraints, constraints that we can enable for our passwords. Um, it is up to you to decide which one to enable. Um, and I would say don't overdo it because if the rules are too hostile, then [00:05:00] usually what the result is that, you know, the result is exactly the opposite.

Like people find ways around it and use weak passwords, especially those like a very frequent rotation of passwords, like every 60 days or 90 days or something like that. Uh, that can be very hostile. Uh, so I would say use, use common sense when deciding which rules you want to enable. Uh, I personally believe that having passwords that are long enough, it's already like the we've covered 80% of, of the work just with that.

Um, so yeah, it depends, but it depends on when the policy in your organization. Um, there is another tool in Drupal that [00:06:00] that helps us with solving these problems, and it's called Flood Control. Flood control is is basically a, an API that comes with Drupal core.

So it's, it's a service that, that you can use in your custom code if you want. It basically it lets you register events and define what the rate limit for this event is, and then floods, you can ask flood every time when this event happens. If the rate limit it has been reached or not, and then you can react.

Um, so you could do that. Like if you implement an API endpoint or something like that, you could use flood to limit requests from a given IP or something like that. Uh, but then in [00:07:00] Drupal core we use flood to protect the, the login forms. Um, and we're basically counting how many failed attempts to log in there are from a given IP.

And then if a certain limit is reached then the, the login will be disabled for, for some period of time. And this is quite good protection. Uh, but it's something to be aware of. If you, I don't know a lot of users coming from, from a single IP at the same time, then this could be triggered unintentionally and prevent users from logging in.

Um, so something to be aware of, if you're using [00:08:00] some other framework most of them would have some kind of API that would do similar thing. Um, or no, if it doesn't and if you need something like that, you can always look at the implementation that comes with Drupal and learn from it, and that's something I really like about open source.

It's much easier to learn in the open-source world than in some other environments where knowledge and code is not shared so freely.

Another tool that it's used quite often nowadays is two factor authentication and Drupal has a nice module for that.

It integrates with Google Authenticator, but you know, it's also pluggable, so you can find plugins for other systems as well. [00:09:00] Um, Or if you have to use something really weird, you can write your own plugin and still use the main API. Um, sometimes people don't want to enable TFA for all users because, you know, sometimes it's, this would scare users off.

Um, and we don't want to do that. Uh, so a good compromise that it's sometimes used is to allow logins without TFA for ordinary users, and then to require them for users with elevated levels of permissions. And you can control that through roles and permission systems. Um, so you can tweak the behavior of the module in the way that suits you best.

Any questions or comments about this topic?

Attendee: What's the recommendation for? Um, passwordless authentication is Drupal supporting it. Um, more generally speaking. Um, you recommend that?

Yeah. These are like, these are like, you know you only ask the user for their phone number or email address, and then you, you send them the magic link and then they log in there. So you never have to worry about their passwords being long or short. You don't have to actually worry about that at all.

Janez Urevc: Yeah. That's definitely an option if that works for you. Um, I have to be honest, I'm not sure. I don't know if there is any module that would do that out of the box. I would think that there is, [00:11:00]

Attendee: Yeah, yeah. There are a few in like D7, D8. Um, but yeah, we've thought about, we just haven't implemented anything and there hasn't been a a need for it yet, but there's definitely stuff out there that can, that can do things like that, where, you know, you get a code to your mobile or, you know, code to your email, then you can log in without having to yeah.

Remember your password, anything like that?

Michael Meyers: There's one called Passwordless. Um, that's been around for 10 years. Um, it looks like there's, isn't a Drupal 8 version, at least. Um, so, you know, I'm sure there's some stuff out there.

Attendee: Yeah. Yeah. And we actually have, like, we use SMS for, I need this for a couple of different things.

And so a lot of users, like, would already have a phone number on a file that could be used.

Michael Meyers: There's definitely multifactor authentication modules out there that we use on a lot of projects, [00:12:00] TFA, SMS.

Attendee: Yeah. We don't have TFA across the board yet, but we'd probably start by, I think we need to actually start doing it for administrators to begin with.

Michael Meyers: Definitely that's exactly, you know where a lot of our projects start at a minimum you know, the Drupal association, for example, anybody on the security team or access to privileged systems is required to use TFA. Um, but it's not a requirement it's optional for me and may not even be available for, for most users.

Attendee: Right.

Michael Meyers: And so we manage the infrastructure and the applications and whatnot. So we put that in place, but yeah. So.

Attendee: Yeah, internally we internally we have TFA everywhere, but for our site users and like their, you know, our customers that are also administrators, like we need to get them on TFA.

Michael Meyers: Um, one of my my favorite things in security, the at the hive systems, [00:13:00] the password table for 2022 came out yesterday and I just pasted it in the chat to everyone. Um, and this always fascinates me. It lists the time it takes to brute force your password given like the state of current technology. Um, and it's, it's crazy.

Like if your password is less than like, you know, eight characters or nine characters, it can be cracked in like two seconds. Um, you know, even if you have, you know, numbers, letters, uppercase, lowercase, symbols, et cetera, you know, a nine character password without parallel processing can be cracked in 30 minutes.

So two days, max so you really need to use as long strong passwords to have any, any real level of security. It's, it's really crazy how easy it is to crack, you know, short, even complex passwords.

Janez Urevc: Yes. And [00:14:00] that's another, like, obviously if you have password manager, then, then you can generate random passwords that are really long and just, you know, then, then you're, you're covered.

I, I did experience a few websites where they wouldn't let me to use password that is longer than 15 characters, which is, which is insane because my passwords are usually like 50 characters or more. And then a lot of times like sites would just break which makes me wonder why that's the case. Um, or like another recommendation if you're not using password manager, but you want to use long passwords that are easy to remember. Just write down a sentence that makes sense to you. Like whatever it just instead of using and remembering characters just write down words. [00:15:00] Uh, and if you write down a whole sentence that two years ago, when I met my best friends in downtown was a really great weather or something like that.

Um, you immediately have a really long password or password that is easy to remember.

Um, so maybe something to consider. Um, in terms of passwordless login. It's not strictly passwordless login, but if you integrate with third-party auth providers, which for Drupal, there are many modules that, that let you do that.

Um, you're not dealing with users' passwords either. And usually these third party providers will have things like TFA, what not. So [00:16:00] we're kind of protected from, from that front, but then there's also single point of failure. So if that provider has a problem, you might have, will probably have a problem as well.

So it's always a trade-off.