sadik fanan sadikfanan@... writes:
Hi , the above mentioned solution didnt worked for me ..
...i have tried both the ways mentioned above ...i
already have access.py in my admin/models folder but it didnt worked outit
was giving error on keywords like 'DEMO_MODE' and 'restricted'i
The suggestion above was not for admin but for auth. It can be adapted
to be used for admin.
On Oct 3, 10:10 pm, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
make a file models/plugin_conditionalrecaptcha.py which contains:
MAX_LOGIN_FAILURES = 3
RECAPTCHA_PUBLIC_KEY = ''
Hi , i am developing an online booking system on GAE..
.the developement is allmost
complete...recently i have come to know about brutforce attacks on web based
application for admin login...
my application is in web2py framework
(python)...can anyone here please guide me on a functionality
Looks like this has been implemented in admin --
see
http://code.google.com/p/web2py/source/browse/applications/admin/models/access.py#55.
Looks like 5 login attempts allowed from a given IP address per hour.
Anthony
On Monday, October 3, 2011 7:16:50 PM UTC-4, sadik fanan wrote:
Hi , i
make a file models/plugin_conditionalrecaptcha.py which contains:
MAX_LOGIN_FAILURES = 3
RECAPTCHA_PUBLIC_KEY = ''
RECAPTCHA_PRIVATE_KEY = ''
def _():
from gluon.tools import Recaptcha
key = 'login_from:%s' % request.env.remote_addr
num_login_attempts = cache.ram(key,lambda:0,None)
Massimo Di Pierro massimo.dipierro@... writes:
Hi , this didnt worked for ...i have tried both the ways mentioned above ...i
already have access.py in my admin/models folder but it didnt worked outit
was giving error on keywords like 'DEMO_MODE' and 'restricted'i also tried
the
that cannot be done. The admin password is set locally always, never
remotely (unless you change it via admin).
On Jul 12, 7:55 pm, Anthony abasta...@gmail.com wrote:
If you add a complexity requirement, make it for remote connections only.
Anthony
On Tuesday, July 12, 2011 6:32:48 PM
I think AB means that the complexity of the Admin password can be analysed
when remote connections are made, and if they don't pass some requirement,
then do something. I haven't thought it through fully either, and tbh I
don't think we need to enforce complexity either. Would it not be
I have created Issue 336 with a patch that adds brute-force attack
protection to the admin application using the input gathered from everyone:
http://code.google.com/p/web2py/issues/detail?id=336
This does NOT add a password complexity requirement, as it seems this is a
touchy issue at the
On Tuesday, July 12, 2011 2:28:10 AM UTC+2, pbreit wrote:
From the code, it looks like admin is accessible via https *OR* localhost.
I had thought localhost was a requirement by default since otherwise it
seems too easy to break in to admin by just trying a bunch of passwords.
Is there a
If I'm not mistaken, without the localhost requirement, a fraudster can go to
/admin and run a pretty simple dictionary attack since they only need to guess
the password.
On Tuesday, July 12, 2011 9:33:13 AM UTC+2, pbreit wrote:
If I'm not mistaken, without the localhost requirement, a fraudster can go
to /admin and run a pretty simple dictionary attack since they only need to
guess the password.
Ok, as opposed to being required to know server, user and
After so many attempts, admin should block the IP address attempting to gain
access. Further, an invalid password, should require a 5 second timeout.
After maybe 5 attempts, block the IP. The DenyHosts script that is used to
prevent SSH brute force attacks does the same thing basically.
And maybe we should require some level of complexity on the admin passwords.
The other day I set my dev machine's password to a single letter. I think
that could be a potential security problem :)
I like the timeout/delay idea for a failed password, and I very much like
the IP block after a number of failed attempts, but I am not too fond of a
complexity requirement. During development on my local machine (bound to
localhost), my standard admin password is a. I would have to have to
On Tuesday, July 12, 2011 3:33:13 AM UTC-4, pbreit wrote:
If I'm not mistaken, without the localhost requirement, a fraudster can go
to /admin and run a pretty simple dictionary attack since they only need to
guess the password.
Alternatively, you could just use a strong random password
Well, as far as the delay and the blocking of the IP, I put this together,
which would go somewhere in the /admin/models/access.py file, but I'd like
to get some comments, as I've never coded this type of thing before so I'd
like to know if there's a better way to code it, and what problems it
One quick change: In failed_login(), the line:
times_denied = 0
Should really be:
times_denied = 1
That looks generally right, but you should invalidate the cache inside
write_hosts_deny(), and I am fairly sure the *with* statement only arrived
in 2.5.
Well, support for Python 2.4 was officially dropped with version 1.96.1, so
I don't think 'with' will be a problem. You're right about the cache
invalidation. Nice catch!
On Tuesday, July 12, 2011 4:14:42 PM UTC+2, Ross Peoples wrote:
Well, support for Python 2.4 was officially dropped with version 1.96.1,
I was not aware of that...although I do recall there was a discussion about
doing so.
I was not suggesting that we needed any immediate changes to trunk but I
think it's good to be mindful of these types of things. The key is striking
the right balance between usability, security and complexity.
we can make a delay default to 1 second and double it every failed
attempt.
we should add complexity. I would take a patch or add an issue in
google code.
On Jul 12, 8:01 am, cjrh caleb.hatti...@gmail.com wrote:
I like the timeout/delay idea for a failed password, and I very much like
the IP
Please don´t make a mandotary complexity. On my dev site I use a simple
password and it doesn´t bother me if somebody breaks in.
Delay sounds good.
Kenneth
we can make a delay default to 1 second and double it every failed
attempt.
we should add complexity. I would take a patch or add an
If you add a complexity requirement, make it for remote connections only.
Anthony
On Tuesday, July 12, 2011 6:32:48 PM UTC-4, Massimo Di Pierro wrote:
we can make a delay default to 1 second and double it every failed
attempt.
we should add complexity. I would take a patch or add an issue
This can work.
On 13 Jul 2011, at 2:55 AM, Anthony abasta...@gmail.com wrote:
If you add a complexity requirement, make it for remote connections only.
Anthony
On Tuesday, July 12, 2011 6:32:48 PM UTC-4, Massimo Di Pierro wrote:
we can make a delay default to 1 second and double it
You can change your requirements in applications/admin/models/
access.py
On Jul 11, 7:28 pm, pbreit pbreitenb...@gmail.com wrote:
From the code, it looks like admin is accessible via https *OR* localhost. I
had thought localhost was a requirement by default since otherwise it seems
too easy
I made two changes which seem to me necessary for decent security:
In /admin I switched is_local from elif to if:
if request.env.http_x_forwarded_for or request.is_https:
session.secure()
if not request.is_local and not DEMO_MODE:
raise HTTP(200, T('Admin is disabled because insecure
The first change is fine but it will not go in trunk because people
expect to be able to login in admin remotely. It requires ssl anyway
and sessions expire in 1h.
The second change may be a problem. appadmin require login in admin,
not necessarily in the auth of the app. Anyway, that depends on
29 matches
Mail list logo