On Mar 16, 12:11 am, Tai Lee wrote:
> 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.
I agree with this, and with the many people in this thread who have
come to the
I have just read whole thread again and I'm happy to see there are many
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'
At the risk of bike-shedding this to death - if the current behavior
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 +0
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 ar
2011/3/15 Juan Pablo Martínez
> 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 ques
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. "
Carelessness or neglect of a click in the admin should't call into
question the admin with the justification
On Mon, 2011-03-14 at 15:57 +, Tom Evans wrote:
> 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 ha
>
> 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 sec
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.
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.")
On 14 March 2011 17:14, Rohit Sethi wrote:
> 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.h
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 betwee
2011/3/14 Juan Pablo Martínez :
> 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 -
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.
2011/3/14 artemy tregubenko
> is visible only
--
You received this message because you are subscribed to
Again: this change does not compromise security, because it's effect is
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 chan
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
whe
To summarize - if I understand correctly the only way a more specific
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
+1 for giving a correct message. It has bitten me more than once, and I
really don't think it would make any attack harder.
The information you would give is the same information that can be acquired
by logging in to the main site first, and then trying to log in to the admin
site. So at the momen
I think some people seem to be confused about what is being asked for.
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
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
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
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
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 mes
+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
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 fie
34 matches
Mail list logo
