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 sm
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 p
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, se
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 f
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
> 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
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
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
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 go
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 becaus
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 use
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 mor
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 informa
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* barrier
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
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.
>
+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
17 matches
Mail list logo
