Using the standard auth in Django, if an inactive user tries to login, they get the error message that either the username or password is incorrect. To me this is unexpected because in django/contrib/auth forms.py on line 217 there is an error message that could say the user is inactive. The authenticate function in the form is returning a None for the user. The authenticate function in init.py does this on line 77:
user = backend.authenticate(request, **credentials)
I traced the reason for this back to django/contrib/auth backends.py line 48. If it is changed from:
if user.check_password(password) and self.user_can_authenticate(user):
to
if user.check_password(password):
Then if a user exists but is inactive and tries to login, they will now get the error message This account is inactive. If a user exists and is active, they login without an error. This is what I originally expected to happen.
I’m wondering what I do with this information, if anything. Would this be a feature request to the Django project? Or is it just something that I deal with on my own?
Thank you. You don’t have to answer this, but if you have time could you explain a bit about how the active/inactive status gets leaked? I did see in the ticket you linked that username status can be leaked by looking at the time to authenticate (users taking more time to authenticate). I think I’ll need to work on Django for a few more years before I’m at a place where I could meaningfully contribute to the code.
If I were to use htmx on the login form to determine if a user is inactive, would that be considered a security risk? The reason this came up is because I had a user that was not able to reset their password but it turns out that they had never completed the user registration when signing up (an activation link is sent to new users).
Grrr. I’d have to read through the issue to see exactly what the story was (which is a bit more than I’ve got bandwidth for at the moment). It might be a good study though! There’s no better way to deepen your knowledge than really looking into a concrete issue until you understand it.
If I were to…
Depends on your threat model I guess. Maybe telling folks is OK for your site. As I glanced at the issue, I think there was mention of a timing attack, showing which accounts were real or not, that was considered the issue. It might be that that doesn’t matter for your site, but wouldn’t be a good default. You have to think these things through. (In general I try to stick with Django’s suggestions, which I know are safe, for as long as possible.)
