[web2py] Re: Admin security: https vs localhost
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 wrote: > 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) > if num_login_attempts >= MAX_LOGIN_FAILURES: > auth.settings.login_captcha = Recaptcha( > request,RECAPTCHA_PUBLIC_KEY,RECAPTCHA_PRIVATE_KEY) > def login_attempt(form,key=key,n=num_login_attempts+1): > cache.ram(key,lambda n=n:n,0) > def login_success(form,key=key): > cache.ram(key,lambda:0,0) > auth.settings.login_onvalidation.append(login_attempt) > auth.settings.login_onaccept.append(login_success) > _() > > On Oct 3, 6:16 pm, sadik fanan wrote: > > > > > > > > > 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 where in , > > the admin > > login will be disabled after 5 wrong password entries ... > > ..is there any kind of > > plugin available for this,,, > > ,or any pre existing code that i can put into my code > > to have this doneplease reply on my mail id : sadikfa...@gmail.com > > . if the > > above mentioned thing is not possible at all > > in web2py , please suggest other ways > > to make more secured admin login
[web2py] Re: Admin security: https vs localhost
sadik fanan 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 also tried the code snippet mentioned above but neither is working...please help me out.
[web2py] Re: Admin security: https vs localhost
Massimo Di Pierro 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 code snippet mentioned above but neither is working...please help me out..
[web2py] Re: Admin security: https vs localhost
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) if num_login_attempts >= MAX_LOGIN_FAILURES: auth.settings.login_captcha = Recaptcha( request,RECAPTCHA_PUBLIC_KEY,RECAPTCHA_PRIVATE_KEY) def login_attempt(form,key=key,n=num_login_attempts+1): cache.ram(key,lambda n=n:n,0) def login_success(form,key=key): cache.ram(key,lambda:0,0) auth.settings.login_onvalidation.append(login_attempt) auth.settings.login_onaccept.append(login_success) _() On Oct 3, 6:16 pm, sadik fanan wrote: > 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 where in , > the admin > login will be disabled after 5 wrong password entries ... > ..is there any kind of > plugin available for this,,, > ,or any pre existing code that i can put into my code > to have this doneplease reply on my mail id : sadikfa...@gmail.com > . if the > above mentioned thing is not possible at all > in web2py , please suggest other ways > to make more secured admin login
[web2py] Re: Admin security: https vs localhost
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 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 where in , > the admin > login will be disabled after 5 wrong password entries ... > ..is there any kind of > plugin available for this,,, > ,or any pre existing code that i can put into my code > to have this doneplease reply on my mail id : sadik...@gmail.com > . if the > above mentioned thing is not possible at all > in web2py , please suggest other ways > to make more secured admin login > >
[web2py] Re: Admin security: https vs localhost
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 where in , the admin login will be disabled after 5 wrong password entries ... ..is there any kind of plugin available for this,,, ,or any pre existing code that i can put into my code to have this doneplease reply on my mail id : sadikfa...@gmail.com . if the above mentioned thing is not possible at all in web2py , please suggest other ways to make more secured admin login
[web2py] Re: Admin security: https vs localhost
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 moment (understandable). Instead, this takes Massimo's idea of an increasing delay based on the number of failed attempts. After the fourth failed login attempt, the user is told they have one more attempt before being locked out. After the fifth failed attempt, the IP address is locked out permanently. If, at any time before the lock out, the user enters the correct password, then failed attempt counter is reset to zero. The Google Code issue has all the details, including instructions on how to unblock an IP address. I have done some extensive testing using a number of use cases, so I hope this works as advertised.
[web2py] Re: Admin security: https vs localhost
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 . I haven't thought it through fully either, and tbh I don't think we need to enforce complexity either. Would it not be sufficient to ask for confirmation when the admin password is entered: e.g. Enter password: a That password is not complex enough and could fall to a brute-force attack. You need len=8, uppercase, lowercase, numeric, and a non-alphanumeric. Do you want to try again ([Y]/n)? Enter password: abc That password is not complex enough and could fall to a brute-force attack. You need len=8, uppercase, lowercase, numeric, and a non-alphanumeric. Do you want to try again ([Y]/n)? Enter password: 12345 That password is not complex enough and could fall to a brute-force attack. You need len=8, uppercase, lowercase, numeric, and a non-alphanumeric. Do you want to try again ([Y]/n)? Enter password: @MyPassword123 Password is sufficiently complex for remote connections. If the user selects "no", the not-complex-enough password still gets used, which is the current behaviour. How say you?
[web2py] Re: Admin security: https vs localhost
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 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 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 wrote: > > > 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 > > deal > > > with a complexity checker during development; and if we then say it will > > be > > > enabled only for production but not dev, then we need more code and > > > error-handling to manage the distinction, and it all becomes a lot of > > work. > > > I think the safeguards that are currently in web2py are quite > > sufficient, > > > and we can improve it a little bit more by penalizing brute force on the > > > password, as pbreit pointed out is currently vulnerable.
Re: [web2py] Re: Admin security: https vs localhost
This can work. On 13 Jul 2011, at 2:55 AM, Anthony 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 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 wrote: > > 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 > > deal > > with a complexity checker during development; and if we then say it will be > > enabled only for production but not dev, then we need more code and > > error-handling to manage the distinction, and it all becomes a lot of work. > > I think the safeguards that are currently in web2py are quite sufficient, > > and we can improve it a little bit more by penalizing brute force on the > > password, as pbreit pointed out is currently vulnerable.
[web2py] Re: Admin security: https vs localhost
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 in > google code. > > On Jul 12, 8:01 am, cjrh wrote: > > 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 > deal > > with a complexity checker during development; and if we then say it will > be > > enabled only for production but not dev, then we need more code and > > error-handling to manage the distinction, and it all becomes a lot of > work. > > I think the safeguards that are currently in web2py are quite > sufficient, > > and we can improve it a little bit more by penalizing brute force on the > > password, as pbreit pointed out is currently vulnerable.
Re: [web2py] Re: Admin security: https vs localhost
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 issue in google code. On Jul 12, 8:01 am, cjrh wrote: 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 deal with a complexity checker during development; and if we then say it will be enabled only for production but not dev, then we need more code and error-handling to manage the distinction, and it all becomes a lot of work. I think the safeguards that are currently in web2py are quite sufficient, and we can improve it a little bit more by penalizing brute force on the password, as pbreit pointed out is currently vulnerable.
[web2py] Re: Admin security: https vs localhost
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 wrote: > 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 deal > with a complexity checker during development; and if we then say it will be > enabled only for production but not dev, then we need more code and > error-handling to manage the distinction, and it all becomes a lot of work. > I think the safeguards that are currently in web2py are quite sufficient, > and we can improve it a little bit more by penalizing brute force on the > password, as pbreit pointed out is currently vulnerable.
[web2py] Re: Admin security: https vs localhost
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.
[web2py] Re: Admin security: https vs localhost
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.
[web2py] Re: Admin security: https vs localhost
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!
[web2py] Re: Admin security: https vs localhost
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.
[web2py] Re: Admin security: https vs localhost
One quick change: In failed_login(), the line: times_denied = 0 Should really be: times_denied = 1
[web2py] Re: Admin security: https vs localhost
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 might
cause:
import os, pickle, time
deny_file = os.path.join(request.folder, 'private', 'hosts.deny')
denied_hosts = cache.ram('admin_denied_hosts', lambda: read_hosts_deny(),
time_expire=3600)
if request.client in denied_hosts:
if denied_hosts[request.client] >= 5:
raise HTTP(200, T(
'admin disabled because too many invalid password attempts'))
def read_hosts_deny():
if os.path.exists(deny_file):
with open(deny_file, 'rb') as f:
d = pickle.load(f)
return d
else:
return {}
def write_hosts_deny():
with open(deny_file, 'wb') as f:
pickle.dump(denied_hosts, f)
def failed_login():
if not request.is_local:
times_denied = 0
if request.client in denied_hosts:
times_denied = denied_hosts[request.client] + 1
denied_hosts[request.client] = times_denied
write_hosts_deny()
time.sleep(5)
def successful_login():
if not request.is_local:
if request.client in denied_hosts:
del denied_hosts[request.client]
write_hosts_deny()
# Then in /admin/controllers/default.py -> index() #
def index():
""" Index handler """
send = request.vars.send
if DEMO_MODE:
session.authorized = True
session.last_time = t0
if not send:
send = URL('site')
if session.authorized:
redirect(send)
elif request.vars.password:
if verify_password(request.vars.password):
session.authorized = True
### ADDED THE FOLLOWING LINE ###
successful_login()
if CHECK_VERSION:
session.check_version = True
else:
session.check_version = False
session.last_time = t0
if isinstance(send, list): # ## why does this happen?
send = str(send[0])
redirect(send)
else:
response.flash = T('invalid password')
ADDED THE FOLLOWING LINE ###
failed_login()
#
return dict(send=send)
This adds a 5 second delay to a failed login attempt, adds the IP address to
the denied_hosts dictionary, along with the number of failed attempts. This
dictionary is cached in RAM and is written to /admin/private/hosts.deny to
maintain the list after a restart. Once a login is successful, the failed
attempt counter is reset to zero.
[web2py] Re: Admin security: https vs localhost
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 on production (and change it periodically). I use Roboform to generate and remember 20+ character random passwords (another good option is Lastpass). Even with some of the other protections being discussed, this is still a good idea. Anthony
[web2py] Re: Admin security: https vs localhost
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 deal with a complexity checker during development; and if we then say it will be enabled only for production but not dev, then we need more code and error-handling to manage the distinction, and it all becomes a lot of work. I think the safeguards that are currently in web2py are quite sufficient, and we can improve it a little bit more by penalizing brute force on the password, as pbreit pointed out is currently vulnerable.
[web2py] Re: Admin security: https vs localhost
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 :)
[web2py] Re: Admin security: https vs localhost
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.
[web2py] Re: Admin security: https vs localhost
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 pass for a similar SSH attack? This is a good point. Perhaps we should add a slight delay in login processing for admin? At least we can make brute force intractable.
[web2py] Re: Admin security: https vs localhost
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.
[web2py] Re: Admin security: https vs localhost
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 difference in security level between accessing admin over https compared to accessing admin over a localhost ssh tunnel?
[web2py] Re: Admin security: https vs localhost
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 your
apps.
On Jul 11, 7:51 pm, pbreit wrote:
> 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 channel'))
>
> In /appadmin, I'm requiring login:
>
> if not auth.user_id: redirect(URL('default', 'user', args='login',
> vars={'_next': '/appadmin'}))
[web2py] Re: Admin security: https vs localhost
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 channel'))
In /appadmin, I'm requiring login:
if not auth.user_id: redirect(URL('default', 'user', args='login',
vars={'_next': '/appadmin'}))
[web2py] Re: Admin security: https vs localhost
You can change your requirements in applications/admin/models/ access.py On Jul 11, 7:28 pm, 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. Or is the > advise to not use https in order to require localhost?
