[Geoserver-users] Implementing No "Account Lockout Policy"

[peter james]

Hi,

We are inserting username and different passwords,but still the account is
not getting locked out.And by response length change,we can able to know
that the password is correct.So the attacker can launch an automated Brute
force attack on the "user login" page to gain privileged access of the
users of the application.

kindly suggest how to implement No "Account Lockout" policy for login page
of user in Apache tomcat? or from any other way or how to implement CAPTCHA
in the login page for validating the user credential values?

Software used:--
Webserver:-Apache tomcat 8.0.44
Java:- JRE 1.8.0_131
Geoserver:- Geoserver version 2.11.1 Web Archive(war) for servlet containers

[P O'Toole]

PJ -

Hi,
We are inserting username and different passwords, but still the account is
not getting locked out. And by response length change, we can able to know
that the password is correct. So the attacker can launch an automated Brute
force attack on the "user login" page to gain privileged access of the
users of the application.
kindly suggest how to implement No "Account Lockout" policy for login page
of user in Apache tomcat? or from any other way or how to implement CAPTCHA
in the login page for validating the user credential values?
Software used:--
Webserver:-Apache tomcat 8.0.44
Java:- JRE 1.8.0_131
Geoserver:- Geoserver version 2.11.1 Web Archive(war) for servlet containers

A few questions before any substantial answers are likely to help:

Do you have an explicit requirement from a client or manager to implement a lockout-policy after X number of guesses, or are you simply worried about brute-forcing in general? Have you measured how quickly guesses can be submitted? And are you allowing users to set/change their own Geoserver passwords here or can they be pre-assigned to something strong?

There are many systems out there which are subject to brute-forcing and there are basically 3 responses: 1) make sure brute-forcing is exceptionally unlikely to work by using/requiring strong passwords and preventing instantaneous success/failure replies from the server so exploring the key-space is slow, 2) block the source-IPs for a while, 3) lock down the account(s) apparently under attack. Note that #3 invites denial attacks if usernames are known or guessable, and #2 has limited effectiveness against serious attackers who can employ more than a single computer. #1 is the only real safeguard (at least in the open Internet) so unless a client is willing to pay for the minor advantages of also having #1 or #2 implemented...

- Patrick


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:
- Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html

Geoserver-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users