Re: Wrong error message when user having is_staff=False tries to login to admin
+1 for this fix. I don't think that security through obscurity is ever a good choice. On Wed, Mar 9, 2011 at 9:42 AM, Sergiy Kuzmenko wrote: > IMO, obscuring the reason for admin site access denial only confuses > 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 > > On Wed, Mar 9, 2011 at 8:18 AM, Yishai Beeri wrote: >> +1 on this. Messages should not give inaccurate information. >> >> 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 >> >> >> >> On Wed, 09 Mar 2011 10:39:53 +0200, artemy tregubenko wrote: >> >>> 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 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
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 On 11 March 2011 07:18, Jeff Hutchins wrote: > +1 for this fix. I don't think that security through obscurity is ever > a good choice. > > On Wed, Mar 9, 2011 at 9:42 AM, Sergiy Kuzmenko > wrote: > > IMO, obscuring the reason for admin site access denial only confuses > > 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 > > > > On Wed, Mar 9, 2011 at 8:18 AM, Yishai Beeri > wrote: > >> +1 on this. Messages should not give inaccurate information. > >> > >> 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 > >> > >> > >> > >> On Wed, 09 Mar 2011 10:39:53 +0200, artemy tregubenko > wrote: > >> > >>> 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 > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Django developers" group. > >> To post to this group, send email to django-developers@googlegroups.com > . > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/django-developers?hl=en. > >> > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > > To post to this group, send email to django-developers@googlegroups.com. > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Add current_app to request and pass it to template loaders.
Some tags you could potentially add 'hidden' values like __theme__ in
the context using RequestContext and then have the tags pass those on
to get_template(). Assuming tags played nicely and always passed along
those values to their nodelists contexts.
Other tags like {% include "app/sometemplate.html"%} get the template
at compile time of the parent template. The compiled template might
be cached, or otherwise re-used - so that approach isn't reliable.
I hope there is a solution I overlooked.
I've implemented something similar to this without threadlocals, using
the new class-based views infrastructure. You can override
TemplateView.get_template_names to return an iterable of template names
(by default it returns [self.template_name], actually defined in
TemplateResponseMixin).
You can then vary what you return based on the request, which is
available as an attribute of the base view class.
Cheers,
Dan
--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.com
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
On Fri, Mar 11, 2011 at 5:18 PM, Jeff Hutchins wrote: > +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 %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
2011/3/11 Juan Pablo Martínez > 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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
On 11 March 2011 14:40, Brian O'Connor wrote: > > 2011/3/11 Juan Pablo Martínez >> >> 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. > 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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
No, it can't be fixed with extra help. The error message is very 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 : > On 11 March 2011 14:40, Brian O'Connor wrote: >> >> 2011/3/11 Juan Pablo Martínez >>> >>> 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. >> > > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#15575: MultipleObjectMixin.paginate_queryset always returns is_paginated=True, despite docs saying otherwise
http://code.djangoproject.com/ticket/15575 Should the patch fix the documentation to match tested behaviour (one passing test in generic_views specifically tests this case), or should the code be patched to meet the expectation of the documentation? -- Martin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
Suppose I'm an attacker. I have obtained valid username and password. I 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. -- arty ( http://arty.name ) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
It's too late for an easy string change, but I think the fix for this 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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
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. It's too late for an easy string change, but I think the fix for this 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 -- arty ( http://arty.name ) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
> If an attacker is brute forcing logins, providing a nondescript error > message here makes life harder. > > That claim doesn't really make sense to me. There's 1 of 2 scenarios in my mind, but I've been wrong before and I'll be wrong many more times in my life. 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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
If I'm a smart attacker, I will pay attention to the error message I get 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. -- arty ( http://arty.name ) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
Whoops hit send instead of delete. On Mar 11, 2011 3:07 PM, "Walter Scheper" wrote: -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #14733: A vote in favor of no validation of .raw() queries
Hi Christophe -- Interesting; I didn't know about these constructs. I'm not opposed to this change, but I am a bit concerned about opening up the ability to use raw() for stuff like UPDATE/DELETE where it'd be a nasty code smell. I'd be interested in your thoughts on that: is there a way we can prevent folks from shooting themselves in the foot this way, or do you think trying itself is futile? Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #14733: A vote in favor of no validation of .raw() queries
On Sat, Mar 12, 2011 at 12:20 PM, Jacob Kaplan-Moss wrote: > Hi Christophe -- > > Interesting; I didn't know about these constructs. > > I'm not opposed to this change, but I am a bit concerned about opening > up the ability to use raw() for stuff like UPDATE/DELETE where it'd be > a nasty code smell. I'd be interested in your thoughts on that: is > there a way we can prevent folks from shooting themselves in the foot > this way, or do you think trying itself is futile? The more I look at this, the more I think any protection is going to be pretty much futile. We could spend a whole lot of time trying to validate all the possible combinations and permutations, and still end up missing viable options on certain databases, or miscategorizing valid calls because of some edge case of parsing (oh - you have a space *before* the third brace...better open a ticket). I think we'd be much better served to document the fact that raw() expects a row of results to be returned from the SQL it is provided, and leave the rest up to consenting adults. We might be able to clean up the UX a bit with error messages that draw attention to the known limitations, but honestly, I don't have any particular problem with an API called "raw" requiring the user to be awake and alert when using it. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
