Wrong error message when user having is_staff=False tries to login to admin
artemy tregubenko
I've recently reported a bug[1] in django but got advice to discuss it
here on django-developers first.
When a user having is_staff=False provides correct username and password
to admin login page, he gets a message "Please enter a correct username
and password. Note that both fields are case-sensitive." This message is
wrong, because username and password are correct. Proper message should be
something like "You do not have permissions to enter admin area."
I want to emphasize once more that when username/password combination is
wrong, message should be about wrong credentials. But when
username/password combination is correct, message should be about
permissions.
Russellm opposed that idea saying: "This isn't a good idea, because it can
be used by an attacker to identify admin accounts. This would be a leak of
potentially sensitive information, narrowing the scope for any attack."
I consider that point not valid for following reasons:
* If attacker has no access to any login or password, he will still see
"wrong password" message.
* If attacker has access to login and password of one user, it won't help
him to know that this user is not an admin.
* If attacker knows all logins and passwords, proposed change won't make
attack any easier: attacker will just try them one after another.
That's why I think that proposed change doesn't weaken security and should
be implemented.
I'm strongly in favor of this change, because my mind was blown off when
during debug I could login to a site with my credentials, but not to admin
section. I've lost some time looking for a bug in my code until I checked
is_staff flag.
1: http://code.djangoproject.com/ticket/15567
--
arty ( http://arty.name )
Yishai Beeri
I think the current behavior is also eventually detrimental to security.
In a real life setting this leads to superfluous password resets and
helpdesk queries - all leading to worse password choices by the common
user, besides the wasted time and effort.
Obviously, the new message should only be shown if the usernamd and
password are matched correctly.
Yishai
Sergiy Kuzmenko
the user. If the attacker has user credentials (and knows admin URL!)
the big job has already been done and verifying whether that account
is admin or not is trivial enough. There is no added security in
displaying wrong error message. I'd rather simply return 403 error in
this situation.
Sergiy
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
Jeff Hutchins
a good choice.
Juan Pablo Martínez
You can not enter and that's it.
This is not an error because it is done so on purpose.
Less is more.
-3
Russell Keith-Magee
> +1 for this fix. I don't think that security through obscurity is ever
> a good choice.
This is only a valid criticism if obscurity is your *only* source of
security. However, there's no reason that obscurity can't form one of
*many* barriers.
A good lock should be able to withstand the publication of all the
specifications for how the lock works, but that doesn't mean you have
to make an intruder's life easy by going out of your way to actually
publish those specifications. Every extra piece of obscurity is one
more piece of information that a potential attacker will need to
determine before they can commence an attack.
Yours,
Russ Magee %-)
Brian O'Connor
That's fine. Why give more information than necessary?
You can not enter and that's it.
This is not an error because it is done so on purpose.
Less is more.
-3
This is not an issue of 'giving more information than necessary'. This is about giving information that is not misleading to users. If I were to read that message, I would think I had a typo in my login information, not that I didn't have access.
If you don't have access, the message should say 'This is not a valid administrator account.' or something akin to that.
I'd like to see this fixed as well.
--
Brian O'Connor
Łukasz Rekucki
What is the benefit for the user from this information ? He can't do
anything about it anyway, except for contacting the administrator of
the system. Ordinary users shouldn't even know that the admin
interface exists.
I can imagine a confused staff memeber, that didn't got his account
activated properly, but this can be fixed by putting extra help on
your admin's login page, imho.
--
Łukasz Rekucki
Niran Babalola
specific, but it is very wrong. Personally, I see very little value in
withholding the is_staff information from intruders, but if that needs
to be kept, the error message should be accurate. Something like
"Please enter a correct username and password for a %(site)s staff
member. Note that both fields are case-sensitive"
- Niran
2011/3/11 Łukasz Rekucki <lrek...@gmail.com>:
artemy tregubenko
tried those on main site and it worked. I tried those on admin site and it
didn't work. I understand that is_staff=False for this user. This is open
information.
Yet some people try to hide this open information from good users.
That's a very common error in security efforts: make life of good people
harder while nothing changes for bad guys.
> That's fine. Why give more information than necessary?
> You can not enter and that's it.
> This is not an error because it is done so on purpose.
> Less is more.
Paul McMillan
problem should probably be to append something to the effect of "or
you don't have permission to log in here." to that message.
If an attacker is brute forcing logins, providing a nondescript error
message here makes life harder.
-Paul
artemy tregubenko
"I want to emphasize once more that when username/password combination is
wrong, message should be about wrong credentials. But when
username/password combination is correct, message should be about
permissions."
Bruteforcing isn't related to desired behavior in any way.
Brian O'Connor
If an attacker is brute forcing logins, providing a nondescript error
message here makes life harder.
Scenario 1: The site has an open login system where there are regular users and admin users (is_staff=True). If an attacker wants to brute force this type of site, they'll simply use the regular public facing login mechanism, verify account credentials and then use them on the admin facing login screen. Get an error, you know they're not an admin.
Scenario 2: The site only has admin users, and there are no _active_ users with is_staff=False. At first it might seem like providing a non-descriptive error message would stop an attacker from brute forcing this type of account.
However, there are _only_ admin users on this site. There will be no active users who would have is_staff=False, and therefore any time an attacker got hold of valid credentials, they would be entered into the admin area.
The only logical thought I can see here is that if there are inactive users in the database, you allow the attacker to stop their attack short when they find the a user with invalid permissions, and go to the next account.
This doesn't seem like enough benefit to justify having a confusing message presented to legitimate users, at least in my opinion.
--
Brian O'Connor
Walter Scheper
On Mar 11, 2011, at 1:33 PM, artemy tregubenko wrote:
> I'm quoting first message in thread:
>
> "I want to emphasize once more that when username/password combination is wrong, message should be about wrong credentials. But when username/password combination is correct, message should be about permissions."
>
> Bruteforcing isn't related to desired behavior in any way.
Almost by definition, in a brute force attack you don't know any valid credentials. The purpose of the attack is to discover valid ones.
If I'm a smart attacker, I will pay attention to the error message I get back from my failed login attempts. If I'm attacking an admin login page and I get told "You don't have permissions to log into the admin page" or "Use a valid admin account" then I know that I very likely have discovered a valid username and password for logging into the non-admin part of the site, which is a breach of security. I will now go login as this user and begin seeing what sorts of holes are available to me from there.
How is this fundamentally any different from a message that says "Wrong password for that username?" Are you advocating that it's better design to tell brute force attackers whenever they hit upon a valid username, because its clearer to valid users what the error is?
As for the error confusing valid users, I fail to see the issue. Users should know already whether they are admins on a site or not, that shouldn't be something they need to discover for themselves.
Walter
artemy tregubenko
> back from my failed login attempts.
If you're a smart attacker, you won't bruteforce credentials for admin
site, you will bruteforce credentials for main site. This way you'd get
much more credentials, if credentials for main site are good enough for
you.
If credentials for main site aren't good enough and you need credentials
for admin site then yes, you'd bruteforce admin site, but you won't in any
way benefit from knowing that some credentials are ok for main site only.
Walter Scheper
Whoops hit send instead of delete.
Peter
I think the suggestion is that you should get this new "not an admin
account" message iff
the provided username _and_ password are correct. If you don't have
permission, but
provide an incorrect password, then you still get the old message.
That way, you can only gain more information than with the current
system when you have
both a username and correct password. If an attacker has that
information, then frankly,
it's too late to be thinking about how to make things more secure.
Regards,
Peter
TiNo
Rohit Sethi
error message can result in a problem is the following scenario:
1) An attacker correctly guesses credentials for a user on the admin
site
2) The attacker does not try to authenticate with the same credentials
on the regular site
The attacker is able to determine that the credentials are correct AND
the user is *not* an administrator. This is only a risk if #2 holds,
which leads to me believe it's a very low risk scenario. You could
argue there's some incremental security benefit in withholding
information, but I'm not sure it justifies the hit to usability.
My primary job is to help prevent security vulnerabilities, but I'd
still say +1 for giving a more specific message in this context.
Juan Pablo Martínez
why it has to amend the current when the change is more vulnerable end
up leaving the system.
To me what should be discussed now is not whether to put the correct
message or not (because that is "correct "), you should discuss
whether to allow changes made in some way, compromise security.
--
:: juanpex
artemy tregubenko
visible only *after* security is compromised: when attacker has valid
username and password for the site.
> I understand that the "correct" message is another, but I do not see
> why it has to amend the current when the change is more vulnerable end
> up leaving the system.
> To me what should be discussed now is not whether to put the correct
> message or not (because that is "correct "), you should discuss
> whether to allow changes made in some way, compromise security.
Juan Pablo Martínez
If I dont know the username and password I can also try username and password and wait for the system to send another different error message. then I get valid credentials.
Tom Evans
> I dont think so.
> If I dont know the username and password I
> can also try username and password and wait for the system
> to send another different error message. then I get valid credentials.
This is one of my bug-bears with the current authentication system -
it has no concept of role. The current action when an identified user
visits the admin site is to display a login form, which is totally
wrong in my opinion. The user has already presented credentials, which
we have accepted, so why should we expect them to have another
different set of credentials?
Similarly, most restricted access views are currently protected by the
login_required decorator. Again, this is pretty good, but it doesn't
solve the authorization issue. With the vast majority of views I
decorate with @login_required, I actually need three states:
Unidentified -> login page
Identified, but no access -> homepage, with error message
Identified, access -> allow through
From the AAA, Django currently only really provides Authentication
(auth) and Access Controls (permissions). It doesn't really provide
any mechanism for Authorization.
In my projects, we have utilized _ExtendedCheckLogin (the class from
which @login_required is built around in 1.2 IIRC) to provide
@user_passes_test decorator, which takes a lambda function which is
called with the current user, and @logged_in_permission_required,
which is a specialization of @user_passes_test that simply takes a
permission name.
So, why am I jabbering about AAA, when this is about correctness of an
error message on the admin site? Well, the two dovetail quite nicely.
Imagine that django has this full AAA support. The admin views are no
longer decorated with @login_required, since they require a lot more
than that. Instead, they look something like this:
@user_passes_test(lambda u: u.is_staff or u.is_superuser)
def index(request):
...
Now this whole argument is moot. If the logged in user does not have
access to the admin site, they are sent to the homepage with a message
explaining that they don't have access. If they aren't logged in, they
get sent to the login page in order to do so. We now never have to
confuse our users by showing a logged in user a login form.
Now lets examine the extra information we may be leaking to an attacker:
If the site has both admin login, and regular login, then there is no
additional risk; an attacker detecting that a user account exists and
that they have the right credentials for that user by detecting a
change in error message from logging into a protected resource that
the user does not have access to is no different than an attacker
confirming an account exists and they have the right credentials by
actually logging into the account in the main interface.
If the site only has admin login, then the attacker would be able to
determine that there is a user account with these credentials.
However, this would be credentials for a user who cannot themselves
log into the site, making them of limited usefulness.
I hope this wasn't too long to read!
Cheers
Tom
Rohit Sethi
credentials for an end user who is not an admin user. You seem to be
referring to Response Information Discrepancy Information Exposure
(http://cwe.mitre.org/data/definitions/204.html) which is generally
about differentiating between incorrect user-name versus incorrect
password. The security benefit here is negligible since the only
scenario it protects against is when an attacker who can access the
admin interface is either unaware or unwilling to try the same attack
on the end user interface.
Łukasz Rekucki
> To re-iterate, you would get this message iff you have the correct
> credentials for an end user who is not an admin user. You seem to be
> referring to Response Information Discrepancy Information Exposure
> (http://cwe.mitre.org/data/definitions/204.html) which is generally
> about differentiating between incorrect user-name versus incorrect
> password. The security benefit here is negligible since the only
> scenario it protects against is when an attacker who can access the
> admin interface is either unaware or unwilling to try the same attack
> on the end user interface.
Which might be a valid concern if your public-facing login interface
highly protected, but your admin interface is not (for example,
because it's only available on your protected intranet). Sure, it's
the edgiest of edge cases and if you care enough, you should have
applied the same security measures in the first place. So yes, this
most likely is not a security issue at all.
OTOH, I don't see a valid usage scenario not involving an admin who
has 2 accounts in the system and forgot which one was the proper one.
Now we can bikeshed to all eternity that the message is wrong (it's a
bit right too - you didn't gave valid creditials for this site. The
fact that your main site and admin site use the same user base is an
implementation detail), but that won't help anyone.
Anyway, Django 1.3 add an option to change the auth form used by
admin[1], so changing that message isn't that hard now. Another option
I already mentioned is adding extra help text in the template (you can
even make it display only if the form is invalid).
[1]: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.login_form
PS. If you're really concerned about messages from admin you should be
really outraged by _("Your e-mail address is not your username. Try
'%s' instead.") % user.username
--
Łukasz Rekucki
artemy tregubenko
> has 2 accounts in the system and forgot which one was the proper one.
<skip>
> PS. If you're really concerned about messages from admin you should be
> really outraged by _("Your e-mail address is not your username. Try
> '%s' instead.") % user.username
That example is bad, but not misleading. Message about wrong credentials
is misleading. It misled me to waste whole hour figuring out what's wrong
with my login system - that's a usage scenario I want to fix.
Scenario: developer uses django to create a site, has is_staff=False for
some reason, django actively prevents debugging that issue.
Brian O'Connor
Which might be a valid concern if your public-facing login interface
highly protected, but your admin interface is not (for example,
because it's only available on your protected intranet). Sure, it's
the edgiest of edge cases and if you care enough, you should have
applied the same security measures in the first place. So yes, this
most likely is not a security issue at all.
--
Brian O'Connor
Nick Phillips
> This is one of my bug-bears with the current authentication system -
> it has no concept of role. The current action when an identified user
> visits the admin site is to display a login form, which is totally
> wrong in my opinion. The user has already presented credentials, which
> we have accepted, so why should we expect them to have another
> different set of credentials?
>
> Similarly, most restricted access views are currently protected by the
> login_required decorator. Again, this is pretty good, but it doesn't
> solve the authorization issue. With the vast majority of views I
> decorate with @login_required, I actually need three states:
>
> Unidentified -> login page
> Identified, but no access -> homepage, with error message
> Identified, access -> allow through
Spot on, IMO - it's muddling authentication and authorization up
together. The user is authenticated, and shouldn't be arbitrarily given
the impression that they're not when they try to access a page to which
they don't have access. There's nothing "special" about the admin here,
except that it is provided as part of the "batteries included". How does
your site respond when a user tried to access any other URL to which
they are denied access? Whatever happens there is probably what should
happen when they try to access the admin. It could be a 403, a redirect
to homepage, a forced logout with disabling of account and email to
admin, could be all sorts of things, depending on the site.
The question should probably be "how can we allow the developer to
specify the desired behaviour when the user attempts to access a URL to
which they have no access?" - subject to the usual provision of sensible
defaults etc.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.p...@otago.ac.nz
# these statements are my own, not those of the University of Otago
Juan Pablo Martínez
on most sites. Someone who has access to the admin has access to most
or all information. There is no "one more app. "
Carelessness or neglect of a click in the admin should't call into
question the admin with the justification "that does not happen
again."
If the application is used only in Intranet or not is entirely
separate from whether to put the right message or not.
I think if everyone is going to fix "contrib" to your needs the
contrib lost all independence.
1.3 will create a special form and then you can change the message.
I do not think the amendment is necessary.
Regards,
Brian O'Connor
The admin is not "one more app" is (if I may) the app with more weight
on most sites. Someone who has access to the admin has access to most
or all information. There is no "one more app. "
This has nothing to do with the argument here. The account in question, as already stated many times, has no access to the admin site. That's the whole point of this discussion.
Carelessness or neglect of a click in the admin should't call into
question the admin with the justification "that does not happen
again."
This has to do with deliberately misleading users. I've been stuck by this at least once in my django career, and artemy has too. People make mistakes, it happens.
I think if everyone is going to fix "contrib" to your needs the
contrib lost all independence.
I especially don't understand this statement. The whole point of django-developers is to discuss development of django, and by extension (because there are no other lists, as far as I'm aware) the contrib modules. Everyone comes here to help make the project better, to help fit their needs. That's the whole point, as far as I'm concerned.
A reasonable suggestion was made, in which a few people came back and said that by doing this improvement, it would open a security issue. Myself, and others have stated that in fact, this would not be a security issue, and have provided examples.
At this point, I'll absolutely never forget to check the is_staff flag purely because I've been following this discussion. What I don't understand is why there is such a huge opposition to the change.
--
Brian O'Connor
Yishai Beeri
included the correct message (user can't access the admin) - would we
seriously consider a ticket asking to replace it with the current
"misleading/more secure" message, for security's sake?
On Wed, 16 Mar 2011 06:11:18 +0200, Tai Lee <real....@mrmachine.net>
wrote:
> I also don't think it should be considered a security vulnerability to
> reveal that an authenticated user does not have permission to access
> the admin (or any other) app.
>
> If the credentials are valid and they authenticate against the defined
> authentication backends, then we should assume that we are talking to
> a trusted authenticated user and we should present error messages that
> are at the very least not misleading.
>
> Assuming that any authenticated user might be an attacker who has
> brute forced a password and presenting obscure error messages to
> authenticated users is not helping anybody.
>
> Cheers.
> Tai.
Tai Lee
reveal that an authenticated user does not have permission to access
the admin (or any other) app.
If the credentials are valid and they authenticate against the defined
authentication backends, then we should assume that we are talking to
a trusted authenticated user and we should present error messages that
are at the very least not misleading.
Assuming that any authenticated user might be an attacker who has
brute forced a password and presenting obscure error messages to
authenticated users is not helping anybody.
Cheers.
Tai.
On Mar 16, 3:41 am, "Brian O'Connor" <gatzby...@gmail.com> wrote:
artemy tregubenko
people supporting my proposal. They have written thorough objections to
criticism.
So what would be the decision on this issue? Would Django make good guys'
life harder while nothing changes for bad guys?
> Hello.
>
> I've recently reported a bug[1] in django but got advice to discuss it
> here on django-developers first.
>
> When a user having is_staff=False provides correct username and password
> to admin login page, he gets a message "Please enter a correct username
> and password. Note that both fields are case-sensitive." This message is
> wrong, because username and password are correct. Proper message should
> be something like "You do not have permissions to enter admin area."
>
> I want to emphasize once more that when username/password combination is
> wrong, message should be about wrong credentials. But when
> username/password combination is correct, message should be about
> permissions.
>
> Russellm opposed that idea saying: "This isn't a good idea, because it
> can be used by an attacker to identify admin accounts. This would be a
> leak of potentially sensitive information, narrowing the scope for any
> attack."
>
> I consider that point not valid for following reasons:
>
> * If attacker has no access to any login or password, he will still see
> "wrong password" message.
> * If attacker has access to login and password of one user, it won't
> help him to know that this user is not an admin.
> * If attacker knows all logins and passwords, proposed change won't make
> attack any easier: attacker will just try them one after another.
>
> That's why I think that proposed change doesn't weaken security and
> should be implemented.
>
> I'm strongly in favor of this change, because my mind was blown off when
> during debug I could login to a site with my credentials, but not to
> admin section. I've lost some time looking for a bug in my code until I
> checked is_staff flag.
>
> 1: http://code.djangoproject.com/ticket/15567
Carl Meyer
> Assuming that any authenticated user might be an attacker who has
> brute forced a password and presenting obscure error messages to
> authenticated users is not helping anybody.
come to the conclusion that there is no significant security benefit
to the obfuscated error message here. So I would be +1 to change it.
However, if there are core devs who still feel that there's some
security issue here (Russell?), Paul presented early on what I think
is a pretty good compromise: keep the error message the same in all
cases, but append "or you don't have permission to log in here." so it
actually covers the possible cases and isn't quite so misleading. I
think that change should be uncontroversial.
Carl