Locked Out Signal Parameter Differentiation?

[js-truework]

Hi folks, apologies if there's a better place to bring up this sort of inquiry.

I am setting up account lockouts and wanted to emit audit log events when a lockout occurs. I have my lockout_parameters set to AXES_LOCKOUT_PARAMETERS = ["ip_address", ["username", "user_agent"]] but when I emit an audit log I want to differentiate between when an ip_address alone gets locked out versus when a username+user_agent gets locked out. I'm fairly new to Django's signal handling, but as far as I can tell, it's not currently possible for a signal handler to determine which parameter caused a lockout, is it?

Do we think this would be something that could be implemented in a reasonable way? I think it could be useful just in general to be able to differentiate behaviors when a lockout occurs based on what parameter(s) caused the lockout.

[hirotasoshu]

it's not currently possible for a signal handler to determine which parameter caused a lockout, is it?

Currently it's not possible, because we are only sending request, username and ip_address in signal.

But you can implement custom AxesHandler and change failed logins calculation logic (not just getting maximum failures from all lockout parameters, but maximum failures and lockout parameters). Implementing this in django-axes for cache and database handlers would require changing a lot of underlying APIs, so i don't know if it's worth it.

What do you think, @aleksihakli?

[js-truework]

For what it's worth, I ended up replacing our usage of django-axes because we were only using some of the features and I am about to add some features that would have been fairly difficult to integrate based on my understanding of django-axes (which admittedly isn't as good as I'd like). So if it's too much work, feel free to close, it won't be a blocker for me or anything!

[aleksihakli]

This is a bit use-case specific so it would be great to hear more about the use case you are implementing? Logic can always be added but usually simpler is better for many things, in the baseline implementation at least.

[js-truework]

The motivations were basically two-fold:

1. Metrics on a per-lockout-method basis, e.g. how many lockouts happen based on IP, which IP, vs based on Username+Useragent, which username+useragent? That way a security team can make more informed decisions about where potentially targeted attacks are originating from, or who they are targeting.
2. Allowing IP based lockout but allowing certain explicit allowlists of IPs to never get locked out, while still allowing username+useragent lockouts to happen. E.g. a company users your application and has a corporate proxy that 1000 users all go through, one user failing to login 5 times should not lock out all users for the lockout threshold. I can create a model that allows them to specify the IP networks that they want to explicitly allow, but I couldn't figure out how to inject that logic into the axes lockout decisions very easily. I think this is a bit separate from the differentiation of just the signals, though, so might not be directly relevant.