Re: How do LockOutRealms work ?

[Ognjen Blagojevic]

Mark,

On 31.8.2015 12:42, Mark Thomas wrote:

I experienced situations where the user calls the first level service desk and 
a ticket goes all its way to someone who can read the server logs and 
understand the issue... Not exactly optimal.


I agree. That is why most organisations provide self-service password
reset options that are linked off the login page. After a few failed
attempts to login the user simple resets their password (within whatever
rules the organisation requires) and carries on.


How would that help? The username is still locked out. Even with the new 
password, user is still unable to log in.


-Ognjen

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How do LockOutRealms work ?

[Mark Thomas]

On 01/09/2015 08:11, Ognjen Blagojevic wrote:
> Mark,
> 
> On 31.8.2015 12:42, Mark Thomas wrote:
>>> I experienced situations where the user calls the first level service
>>> desk and a ticket goes all its way to someone who can read the server
>>> logs and understand the issue... Not exactly optimal.
>>
>> I agree. That is why most organisations provide self-service password
>> reset options that are linked off the login page. After a few failed
>> attempts to login the user simple resets their password (within whatever
>> rules the organisation requires) and carries on.
> 
> How would that help? The username is still locked out. Even with the new
> password, user is still unable to log in.

The password reset process unlocks the account.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How do LockOutRealms work ?

[Mark Thomas]

On 31/08/2015 20:28, George Sexton wrote:
> 
> 
> On 8/31/2015 8:54 AM, Christopher Schultz wrote:
>> You also tell them how long they have to wait before they can resume
>> their brute-force attack without wasting their own time.
>>> Must better to let a brute force attacker pound away at a locked
>>> account wasting their resources and probably tripping additional
>>> security measures (like an IP block) for the excessive failures
>>> than it is to tell them what they need to do to keep the
>>> authentication system happy.
>>
> 
> I've started using Fail2Ban because of brute force attacks against
> Postfix-SASL. It would be nice if the LockoutRealm also reported the IP
> address so I could use it to cover Tomcat as well. In it's
> implementation, LockoutRealm gives the user n tries per account (at
> least that's my understanding).

The client IP isn't available to the Realm. It would need an API change.

I typically use the access log to trigger fail2ban with Tomcat since
both the client IP and the 403 response code are present.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How do LockOutRealms work ?

[Sreyan Chakravarty]

In your opinion would a security framework help in doing this ? Like Apache
Shiro ?

On Sun, Aug 30, 2015 at 9:51 PM, Mark Thomas  wrote:

> On 29/08/2015 21:51, Sreyan Chakravarty wrote:
> > Is there any way I can tell the user that what number of login attempt he
> > is on ? While using the LockOutRealm any way to display his login attempt
> > on an html or jsp page ?
>
> With the LockOutRealm as currently written, no.
>
> If you extend it and write some custom code, yes.
>
> I'd think through the risks very carefully before you go down this road.
> Do the benefits to the users out-weight the additional security risks
> this would create?
>
> Mark
>
> >
> > On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Sreyan,
> >
> > On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
>  I am confused with the functioning of LockOutRealms in Tomcat.
> 
>  My questions are as follows-:
> 
> 
>  1. Say user at IP 10.10.10.1 has reached the maximum number of
>  invalid login attempts and is locked out. Now say a user from
>  10.10.10.2 attempts to login, will Tomcat stop him too since he is
>  trying to login for the first time ? If not then how does Tomcat
>  keep track of users that are locked out ? Via there IP's ?
> >
> > If you look at the code [1], you'll see that users are identified by
> > username (or "identifier) and no other factors. So, if you get
> > locked-out from 10.10.10.1, you will also be locked-out from
> > 10.10.10.2. However, the lock-out information is not shared amongst
> > cluster members, so the LockOutRealm really only protects a single
> > member of a cluster.
> >
> > If you need "proper" user-locking, you'll want to mark the user as
> > locked-out in a database or something. You could do that by extending
> > LockOutRealm and taking some other action (such as marking a user as
> > locked in a db) after the registerAuthFailure method completes.
> >
>  2. When a user is locked out what message is displayed ? Can I
>  display a custom HTML page when a user has been locked out ? In
>  other words how much control do I have over the lock out process
>  and what error messages are shown ?
> >
> > It depends upon the type of authenticator you are using. If you use
> > the BasicAuthenticator or DigestAuthenticator, you'll get a 401
> > response, and you can customize what page gets returned with a 401. If
> > you use a FormAuthenticator, you can customize the form-error-page. If
> > you are using an x509Authenticator, you cannot customize anything
> > since the failure occurs at the SSL handshake level.
> >
> > In any case, there does not appear to be a way to tell that the user
> > failed due to too-many-authentication-failures. You could request such
> > as feature, but I would personally think nobody would want to
> > implement it... you don't want to leak-out any information about the
> > authentication process if you don't have to. Failed login = failed
> > login, without further clarification. For a truly secure system, the
> > LockOutRealm should also probably waste some time when a locked-out
> > user is found, to simulate the amount of time it takes to
> > properly-authenticate the user and then fail.
> >
> > Hope that helps,
> > -chris
> >
> > [1]
> > http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
> > /LockOutRealm.java?view=markup
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How do LockOutRealms work ?

[Ludovic Pénet]

I can't see what would be the risks with being able to explain "This account is 
locked for X minutes"...


I experienced situations where the user calls the first level service desk and 
a ticket goes all its way to someone who can read the server logs and 
understand the issue... Not exactly optimal.

An option to trigger an exception with more details would be great.

Ludovic

Le 30 août 2015 18:21:51 GMT+02:00, Mark Thomas  a écrit :
>On 29/08/2015 21:51, Sreyan Chakravarty wrote:
>> Is there any way I can tell the user that what number of login
>attempt he
>> is on ? While using the LockOutRealm any way to display his login
>attempt
>> on an html or jsp page ?
>
>With the LockOutRealm as currently written, no.
>
>If you extend it and write some custom code, yes.
>
>I'd think through the risks very carefully before you go down this
>road.
>Do the benefits to the users out-weight the additional security risks
>this would create?
>
>Mark
>
>> 
>> On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>> 
>> Sreyan,
>> 
>> On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
> I am confused with the functioning of LockOutRealms in Tomcat.
>
> My questions are as follows-:
>
>
> 1. Say user at IP 10.10.10.1 has reached the maximum number of
> invalid login attempts and is locked out. Now say a user from
> 10.10.10.2 attempts to login, will Tomcat stop him too since he is
> trying to login for the first time ? If not then how does Tomcat
> keep track of users that are locked out ? Via there IP's ?
>> 
>> If you look at the code [1], you'll see that users are identified by
>> username (or "identifier) and no other factors. So, if you get
>> locked-out from 10.10.10.1, you will also be locked-out from
>> 10.10.10.2. However, the lock-out information is not shared amongst
>> cluster members, so the LockOutRealm really only protects a single
>> member of a cluster.
>> 
>> If you need "proper" user-locking, you'll want to mark the user as
>> locked-out in a database or something. You could do that by extending
>> LockOutRealm and taking some other action (such as marking a user as
>> locked in a db) after the registerAuthFailure method completes.
>> 
> 2. When a user is locked out what message is displayed ? Can I
> display a custom HTML page when a user has been locked out ? In
> other words how much control do I have over the lock out process
> and what error messages are shown ?
>> 
>> It depends upon the type of authenticator you are using. If you use
>> the BasicAuthenticator or DigestAuthenticator, you'll get a 401
>> response, and you can customize what page gets returned with a 401.
>If
>> you use a FormAuthenticator, you can customize the form-error-page.
>If
>> you are using an x509Authenticator, you cannot customize anything
>> since the failure occurs at the SSL handshake level.
>> 
>> In any case, there does not appear to be a way to tell that the user
>> failed due to too-many-authentication-failures. You could request
>such
>> as feature, but I would personally think nobody would want to
>> implement it... you don't want to leak-out any information about the
>> authentication process if you don't have to. Failed login = failed
>> login, without further clarification. For a truly secure system, the
>> LockOutRealm should also probably waste some time when a locked-out
>> user is found, to simulate the amount of time it takes to
>> properly-authenticate the user and then fail.
>> 
>> Hope that helps,
>> -chris
>> 
>> [1]
>>
>http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
>> /LockOutRealm.java?view=markup
>>>
>>>
>-
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>> 
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: How do LockOutRealms work ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/31/15 6:42 AM, Mark Thomas wrote:
> On 31/08/2015 07:32, Ludovic Pénet wrote:
>> I can't see what would be the risks with being able to explain
>> "This account is locked for X minutes"...
> 
> An attacker performing a brute force attack has zero knowledge.
> They have to guess both user names and passwords. Telling an
> attacker an account is locked tells them: a) they have found a
> valid user so they can concentrate on the password. b) their
> behaviour has been noticed

+1

You also tell them how long they have to wait before they can resume
their brute-force attack without wasting their own time.

> Must better to let a brute force attacker pound away at a locked
> account wasting their resources and probably tripping additional
> security measures (like an IP block) for the excessive failures
> than it is to tell them what they need to do to keep the
> authentication system happy.

+1

If they are trying all passwords between "a" and "" and they
get locked-out after "d", then can just wait 5 minutes and start over
with "e" and keep going. If you tell them nothing, they may try "e"
through "" while being continuously locked-out and not realize
they have guessed the password correctly at some point.

Also, if you tell them after 4 attempts they are locked-out, maybe
they won't trip ay alarms you have rigged to look for suspicious login
attempts. IF you let them pound-away on your authentication system,
you will be more easily able to detect the break-in attempt.

>> I experienced situations where the user calls the first level 
>> service desk and a ticket goes all its way to someone who can
>> read the server logs and understand the issue... Not exactly
>> optimal.
> 
> I agree. That is why most organisations provide self-service
> password reset options that are linked off the login page. After a
> few failed attempts to login the user simple resets their password
> (within whatever rules the organisation requires) and carries on.
> 
>> An option to trigger an exception with more details would be
>> great.
> 
> The details are available in the logs.
> 
> I am -1 (for security reasons) on providing any information at all
> to the end user as to why a login may have failed.

+1 (or is that -1)

Tomcat itself isn't going to divulge this information to the user. If
you want to reduce your own security in this way, it's up to you to
code your application specifically to do so.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5GqbAAoJEBzwKT+lPKRYDPUP/iCdUuJBd+Lmo/2Ar2VwrDrk
lmMXv3iT/7RtNnORHzB4m5MCTnYbXxKW1cjoL8yGWPMUtzX0LdgYd8GpYbEyuL+i
HYgwb1ODOmxhrmunD+wCQ03gu179p/vAoijj+7hPmEEs58p0wrO5DItagqEkzadP
ReM2X+lOpWW7wN70lI/DtOdqTyHnmaht8Vmkp1XHq5v6wD5744jFI97Pg7EPLV6H
4M3tITF63vFP5B1+vd4M/avQiHWvEdFEJKs+W+73281T70FPTaztU8VswAxYk8ch
ezxg/UFOQLdz6TjDESrSa9NX0lluQZrrBXCtTtDOu7jh227UyQtGZQm6tMIsD/iE
Zw/mAiXF647mV1o4F7Q0ZINQAKYNzYTIbncWWGOXO5Byzg4Ju8D1xgtl5KvOiY2h
yG3HNFxUj9+GOgD6+7jaO5woHBf+O8TLZPFdwPWst6AB4q3BQ8JGvKQGrEpWI3mh
4P+ZrJvNY6gh1sXpsjzAVpmV/R+3ehiJq9GpfCelIGIKKAjviCP0ZQWjzdPovBud
KufaJFwHY0+HTPeXYi4k40R0QskQ+JJmmsXaBw8Xl9UhqDUBOYkb0wG1M0CtzjnY
y2xew/rnENYh25Bsn1kt6JRCoSilFSOUVrD6mFf/LQsutKpAxcpg1SwHSHbcTyy0
P7ixw+K1ee+tVJF/ehC6
=zQYd
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How do LockOutRealms work ?

[George Sexton]

On 8/31/2015 8:54 AM, Christopher Schultz wrote:
You also tell them how long they have to wait before they can resume 
their brute-force attack without wasting their own time.

Must better to let a brute force attacker pound away at a locked
account wasting their resources and probably tripping additional
security measures (like an IP block) for the excessive failures
than it is to tell them what they need to do to keep the
authentication system happy.




I've started using Fail2Ban because of brute force attacks against 
Postfix-SASL. It would be nice if the LockoutRealm also reported the IP 
address so I could use it to cover Tomcat as well. In it's 
implementation, LockoutRealm gives the user n tries per account (at 
least that's my understanding).


--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: How do LockOutRealms work ?

[Ludovic Pénet]

The points you raise are, of course real and important.
I would probably decide the same as you for a high profile, publicly available 
application.

I however most often have to develop complex apps only used by, at most, 100s 
of corporate users.

I know perimetric security is less and less fashionable but on our intranet, I 
still feel comfortable with more info for the user, ideally coupled with an 
alert to the support team when an account is temporarily locked. 

In the FormAuthenticator valve, you have a parameter to disable session change 
on auth 
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes

This enables session fixation attacks, which seems to be a much more serious 
threat to me. ;)

Thanks any way, you gave us pointers on how to implement a custom auth valve, 
which I might end coding.

With kind regards,



Le 31 août 2015 16:54:20 GMT+02:00, Christopher Schultz 
 a écrit :
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Mark,
>
>On 8/31/15 6:42 AM, Mark Thomas wrote:
>> On 31/08/2015 07:32, Ludovic Pénet wrote:
>>> I can't see what would be the risks with being able to explain
>>> "This account is locked for X minutes"...
>> 
>> An attacker performing a brute force attack has zero knowledge.
>> They have to guess both user names and passwords. Telling an
>> attacker an account is locked tells them: a) they have found a
>> valid user so they can concentrate on the password. b) their
>> behaviour has been noticed
>
>+1
>
>You also tell them how long they have to wait before they can resume
>their brute-force attack without wasting their own time.
>
>> Must better to let a brute force attacker pound away at a locked
>> account wasting their resources and probably tripping additional
>> security measures (like an IP block) for the excessive failures
>> than it is to tell them what they need to do to keep the
>> authentication system happy.
>
>+1
>
>If they are trying all passwords between "a" and "" and they
>get locked-out after "d", then can just wait 5 minutes and start over
>with "e" and keep going. If you tell them nothing, they may try "e"
>through "" while being continuously locked-out and not realize
>they have guessed the password correctly at some point.
>
>Also, if you tell them after 4 attempts they are locked-out, maybe
>they won't trip ay alarms you have rigged to look for suspicious login
>attempts. IF you let them pound-away on your authentication system,
>you will be more easily able to detect the break-in attempt.
>
>>> I experienced situations where the user calls the first level 
>>> service desk and a ticket goes all its way to someone who can
>>> read the server logs and understand the issue... Not exactly
>>> optimal.
>> 
>> I agree. That is why most organisations provide self-service
>> password reset options that are linked off the login page. After a
>> few failed attempts to login the user simple resets their password
>> (within whatever rules the organisation requires) and carries on.
>> 
>>> An option to trigger an exception with more details would be
>>> great.
>> 
>> The details are available in the logs.
>> 
>> I am -1 (for security reasons) on providing any information at all
>> to the end user as to why a login may have failed.
>
>+1 (or is that -1)
>
>Tomcat itself isn't going to divulge this information to the user. If
>you want to reduce your own security in this way, it's up to you to
>code your application specifically to do so.
>
>- -chris
>-BEGIN PGP SIGNATURE-
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJV5GqbAAoJEBzwKT+lPKRYDPUP/iCdUuJBd+Lmo/2Ar2VwrDrk
>lmMXv3iT/7RtNnORHzB4m5MCTnYbXxKW1cjoL8yGWPMUtzX0LdgYd8GpYbEyuL+i
>HYgwb1ODOmxhrmunD+wCQ03gu179p/vAoijj+7hPmEEs58p0wrO5DItagqEkzadP
>ReM2X+lOpWW7wN70lI/DtOdqTyHnmaht8Vmkp1XHq5v6wD5744jFI97Pg7EPLV6H
>4M3tITF63vFP5B1+vd4M/avQiHWvEdFEJKs+W+73281T70FPTaztU8VswAxYk8ch
>ezxg/UFOQLdz6TjDESrSa9NX0lluQZrrBXCtTtDOu7jh227UyQtGZQm6tMIsD/iE
>Zw/mAiXF647mV1o4F7Q0ZINQAKYNzYTIbncWWGOXO5Byzg4Ju8D1xgtl5KvOiY2h
>yG3HNFxUj9+GOgD6+7jaO5woHBf+O8TLZPFdwPWst6AB4q3BQ8JGvKQGrEpWI3mh
>4P+ZrJvNY6gh1sXpsjzAVpmV/R+3ehiJq9GpfCelIGIKKAjviCP0ZQWjzdPovBud
>KufaJFwHY0+HTPeXYi4k40R0QskQ+JJmmsXaBw8Xl9UhqDUBOYkb0wG1M0CtzjnY
>y2xew/rnENYh25Bsn1kt6JRCoSilFSOUVrD6mFf/LQsutKpAxcpg1SwHSHbcTyy0
>P7ixw+K1ee+tVJF/ehC6
>=zQYd
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: How do LockOutRealms work ?

[Mark Thomas]

On 31/08/2015 07:32, Ludovic Pénet wrote:
> I can't see what would be the risks with being able to explain "This account 
> is locked for X minutes"...

An attacker performing a brute force attack has zero knowledge. They
have to guess both user names and passwords. Telling an attacker an
account is locked tells them:
a) they have found a valid user so they can concentrate on the password.
b) their behaviour has been noticed

Must better to let a brute force attacker pound away at a locked account
wasting their resources and probably tripping additional security
measures (like an IP block) for the excessive failures than it is to
tell them what they need to do to keep the authentication system happy.

> I experienced situations where the user calls the first level service desk 
> and a ticket goes all its way to someone who can read the server logs and 
> understand the issue... Not exactly optimal.

I agree. That is why most organisations provide self-service password
reset options that are linked off the login page. After a few failed
attempts to login the user simple resets their password (within whatever
rules the organisation requires) and carries on.

> An option to trigger an exception with more details would be great.

The details are available in the logs.

I am -1 (for security reasons) on providing any information at all to
the end user as to why a login may have failed.

Mark


> 
> Ludovic
> 
> Le 30 août 2015 18:21:51 GMT+02:00, Mark Thomas  a écrit :
>> On 29/08/2015 21:51, Sreyan Chakravarty wrote:
>>> Is there any way I can tell the user that what number of login
>> attempt he
>>> is on ? While using the LockOutRealm any way to display his login
>> attempt
>>> on an html or jsp page ?
>>
>> With the LockOutRealm as currently written, no.
>>
>> If you extend it and write some custom code, yes.
>>
>> I'd think through the risks very carefully before you go down this
>> road.
>> Do the benefits to the users out-weight the additional security risks
>> this would create?
>>
>> Mark
>>
>>>
>>> On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Sreyan,
>>>
>>> On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
>> I am confused with the functioning of LockOutRealms in Tomcat.
>>
>> My questions are as follows-:
>>
>>
>> 1. Say user at IP 10.10.10.1 has reached the maximum number of
>> invalid login attempts and is locked out. Now say a user from
>> 10.10.10.2 attempts to login, will Tomcat stop him too since he is
>> trying to login for the first time ? If not then how does Tomcat
>> keep track of users that are locked out ? Via there IP's ?
>>>
>>> If you look at the code [1], you'll see that users are identified by
>>> username (or "identifier) and no other factors. So, if you get
>>> locked-out from 10.10.10.1, you will also be locked-out from
>>> 10.10.10.2. However, the lock-out information is not shared amongst
>>> cluster members, so the LockOutRealm really only protects a single
>>> member of a cluster.
>>>
>>> If you need "proper" user-locking, you'll want to mark the user as
>>> locked-out in a database or something. You could do that by extending
>>> LockOutRealm and taking some other action (such as marking a user as
>>> locked in a db) after the registerAuthFailure method completes.
>>>
>> 2. When a user is locked out what message is displayed ? Can I
>> display a custom HTML page when a user has been locked out ? In
>> other words how much control do I have over the lock out process
>> and what error messages are shown ?
>>>
>>> It depends upon the type of authenticator you are using. If you use
>>> the BasicAuthenticator or DigestAuthenticator, you'll get a 401
>>> response, and you can customize what page gets returned with a 401.
>> If
>>> you use a FormAuthenticator, you can customize the form-error-page.
>> If
>>> you are using an x509Authenticator, you cannot customize anything
>>> since the failure occurs at the SSL handshake level.
>>>
>>> In any case, there does not appear to be a way to tell that the user
>>> failed due to too-many-authentication-failures. You could request
>> such
>>> as feature, but I would personally think nobody would want to
>>> implement it... you don't want to leak-out any information about the
>>> authentication process if you don't have to. Failed login = failed
>>> login, without further clarification. For a truly secure system, the
>>> LockOutRealm should also probably waste some time when a locked-out
>>> user is found, to simulate the amount of time it takes to
>>> properly-authenticate the user and then fail.
>>>
>>> Hope that helps,
>>> -chris
>>>
>>> [1]
>>>
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
>>> /LockOutRealm.java?view=markup


>> -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For 

Re: How do LockOutRealms work ?

[Mark Thomas]

On 29/08/2015 21:51, Sreyan Chakravarty wrote:
 Is there any way I can tell the user that what number of login attempt he
 is on ? While using the LockOutRealm any way to display his login attempt
 on an html or jsp page ?

With the LockOutRealm as currently written, no.

If you extend it and write some custom code, yes.

I'd think through the risks very carefully before you go down this road.
Do the benefits to the users out-weight the additional security risks
this would create?

Mark

 
 On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:
 
 Sreyan,
 
 On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
 I am confused with the functioning of LockOutRealms in Tomcat.

 My questions are as follows-:


 1. Say user at IP 10.10.10.1 has reached the maximum number of
 invalid login attempts and is locked out. Now say a user from
 10.10.10.2 attempts to login, will Tomcat stop him too since he is
 trying to login for the first time ? If not then how does Tomcat
 keep track of users that are locked out ? Via there IP's ?
 
 If you look at the code [1], you'll see that users are identified by
 username (or identifier) and no other factors. So, if you get
 locked-out from 10.10.10.1, you will also be locked-out from
 10.10.10.2. However, the lock-out information is not shared amongst
 cluster members, so the LockOutRealm really only protects a single
 member of a cluster.
 
 If you need proper user-locking, you'll want to mark the user as
 locked-out in a database or something. You could do that by extending
 LockOutRealm and taking some other action (such as marking a user as
 locked in a db) after the registerAuthFailure method completes.
 
 2. When a user is locked out what message is displayed ? Can I
 display a custom HTML page when a user has been locked out ? In
 other words how much control do I have over the lock out process
 and what error messages are shown ?
 
 It depends upon the type of authenticator you are using. If you use
 the BasicAuthenticator or DigestAuthenticator, you'll get a 401
 response, and you can customize what page gets returned with a 401. If
 you use a FormAuthenticator, you can customize the form-error-page. If
 you are using an x509Authenticator, you cannot customize anything
 since the failure occurs at the SSL handshake level.
 
 In any case, there does not appear to be a way to tell that the user
 failed due to too-many-authentication-failures. You could request such
 as feature, but I would personally think nobody would want to
 implement it... you don't want to leak-out any information about the
 authentication process if you don't have to. Failed login = failed
 login, without further clarification. For a truly secure system, the
 LockOutRealm should also probably waste some time when a locked-out
 user is found, to simulate the amount of time it takes to
 properly-authenticate the user and then fail.
 
 Hope that helps,
 -chris
 
 [1]
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
 /LockOutRealm.java?view=markup

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How do LockOutRealms work ?

[Sreyan Chakravarty]

Is there any way I can tell the user that what number of login attempt he
is on ? While using the LockOutRealm any way to display his login attempt
on an html or jsp page ?

On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sreyan,

 On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
  I am confused with the functioning of LockOutRealms in Tomcat.
 
  My questions are as follows-:
 
 
  1. Say user at IP 10.10.10.1 has reached the maximum number of
  invalid login attempts and is locked out. Now say a user from
  10.10.10.2 attempts to login, will Tomcat stop him too since he is
  trying to login for the first time ? If not then how does Tomcat
  keep track of users that are locked out ? Via there IP's ?

 If you look at the code [1], you'll see that users are identified by
 username (or identifier) and no other factors. So, if you get
 locked-out from 10.10.10.1, you will also be locked-out from
 10.10.10.2. However, the lock-out information is not shared amongst
 cluster members, so the LockOutRealm really only protects a single
 member of a cluster.

 If you need proper user-locking, you'll want to mark the user as
 locked-out in a database or something. You could do that by extending
 LockOutRealm and taking some other action (such as marking a user as
 locked in a db) after the registerAuthFailure method completes.

  2. When a user is locked out what message is displayed ? Can I
  display a custom HTML page when a user has been locked out ? In
  other words how much control do I have over the lock out process
  and what error messages are shown ?

 It depends upon the type of authenticator you are using. If you use
 the BasicAuthenticator or DigestAuthenticator, you'll get a 401
 response, and you can customize what page gets returned with a 401. If
 you use a FormAuthenticator, you can customize the form-error-page. If
 you are using an x509Authenticator, you cannot customize anything
 since the failure occurs at the SSL handshake level.

 In any case, there does not appear to be a way to tell that the user
 failed due to too-many-authentication-failures. You could request such
 as feature, but I would personally think nobody would want to
 implement it... you don't want to leak-out any information about the
 authentication process if you don't have to. Failed login = failed
 login, without further clarification. For a truly secure system, the
 LockOutRealm should also probably waste some time when a locked-out
 user is found, to simulate the amount of time it takes to
 properly-authenticate the user and then fail.

 Hope that helps,
 - -chris

 [1]
 http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
 /LockOutRealm.java?view=markup
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJV2yPWAAoJEBzwKT+lPKRYRM0QAKnl/8bDktDWdDMlWYJZejwu
 UAVl1lgDFN0rm+osfRegAPaBx0ERHZnZiUUWYtEEOAB6XzhgQMfendBpRyzkT7Af
 3TGxPwZwsAbe4sSVrZvi25K3o7CThxn1CymMQPaR0v0uXq2CH+NdKwOcPLsMtyK/
 aofhbNP7Bde3gey6YlzN4PME0Ho+0dxXgI3bGSqtiSp3xWroGRJxsNhKGhvV2Ntj
 gN6O22rlzHvvt21oXxBOkHIHKBdjlsT6TLOt7Lp2alWxAd4e1pcM+KTzVQA35jan
 QkD/vQ8aPUGGc53Vsygnk4nItzMFJJQWUtarCZpjxzKaSBKNMB2ON0C+Occyog+S
 jt8uASbne9gN0oknP5tF5OU+nrhsXW3KcIlOC6uVgGqGvcGUrjEN78Y1ZVgycpyb
 TnZdeGnFYrUFHgC7vadzE1KSbd8hJvJojUX3EgUSj0+liM+HvoIqCXPbL1E7oTra
 qsmZPA8/VfCXQpgIfNBjlv94XpzMPcYxGsoBdG5QQiAeIsEgaX0Uv4zM8mowPbdH
 XDbEWTsTSvEkYv5PRU6C/251zvoxZ5vhMFXeIX6zN075KmflhM5AQ/LUd6qCg0mz
 r/memt0VqAauRx/i5l04dmLF6FubraBtP8J5sluHkXywmepGGA6MDzJc9HmTTXH5
 N5u8FupQhbCp3x/lSt4w
 =8IkU
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How do LockOutRealms work ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
 I am confused with the functioning of LockOutRealms in Tomcat.
 
 My questions are as follows-:
 
 
 1. Say user at IP 10.10.10.1 has reached the maximum number of 
 invalid login attempts and is locked out. Now say a user from 
 10.10.10.2 attempts to login, will Tomcat stop him too since he is 
 trying to login for the first time ? If not then how does Tomcat
 keep track of users that are locked out ? Via there IP's ?

If you look at the code [1], you'll see that users are identified by
username (or identifier) and no other factors. So, if you get
locked-out from 10.10.10.1, you will also be locked-out from
10.10.10.2. However, the lock-out information is not shared amongst
cluster members, so the LockOutRealm really only protects a single
member of a cluster.

If you need proper user-locking, you'll want to mark the user as
locked-out in a database or something. You could do that by extending
LockOutRealm and taking some other action (such as marking a user as
locked in a db) after the registerAuthFailure method completes.

 2. When a user is locked out what message is displayed ? Can I 
 display a custom HTML page when a user has been locked out ? In
 other words how much control do I have over the lock out process
 and what error messages are shown ?

It depends upon the type of authenticator you are using. If you use
the BasicAuthenticator or DigestAuthenticator, you'll get a 401
response, and you can customize what page gets returned with a 401. If
you use a FormAuthenticator, you can customize the form-error-page. If
you are using an x509Authenticator, you cannot customize anything
since the failure occurs at the SSL handshake level.

In any case, there does not appear to be a way to tell that the user
failed due to too-many-authentication-failures. You could request such
as feature, but I would personally think nobody would want to
implement it... you don't want to leak-out any information about the
authentication process if you don't have to. Failed login = failed
login, without further clarification. For a truly secure system, the
LockOutRealm should also probably waste some time when a locked-out
user is found, to simulate the amount of time it takes to
properly-authenticate the user and then fail.

Hope that helps,
- -chris

[1]
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
/LockOutRealm.java?view=markup
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV2yPWAAoJEBzwKT+lPKRYRM0QAKnl/8bDktDWdDMlWYJZejwu
UAVl1lgDFN0rm+osfRegAPaBx0ERHZnZiUUWYtEEOAB6XzhgQMfendBpRyzkT7Af
3TGxPwZwsAbe4sSVrZvi25K3o7CThxn1CymMQPaR0v0uXq2CH+NdKwOcPLsMtyK/
aofhbNP7Bde3gey6YlzN4PME0Ho+0dxXgI3bGSqtiSp3xWroGRJxsNhKGhvV2Ntj
gN6O22rlzHvvt21oXxBOkHIHKBdjlsT6TLOt7Lp2alWxAd4e1pcM+KTzVQA35jan
QkD/vQ8aPUGGc53Vsygnk4nItzMFJJQWUtarCZpjxzKaSBKNMB2ON0C+Occyog+S
jt8uASbne9gN0oknP5tF5OU+nrhsXW3KcIlOC6uVgGqGvcGUrjEN78Y1ZVgycpyb
TnZdeGnFYrUFHgC7vadzE1KSbd8hJvJojUX3EgUSj0+liM+HvoIqCXPbL1E7oTra
qsmZPA8/VfCXQpgIfNBjlv94XpzMPcYxGsoBdG5QQiAeIsEgaX0Uv4zM8mowPbdH
XDbEWTsTSvEkYv5PRU6C/251zvoxZ5vhMFXeIX6zN075KmflhM5AQ/LUd6qCg0mz
r/memt0VqAauRx/i5l04dmLF6FubraBtP8J5sluHkXywmepGGA6MDzJc9HmTTXH5
N5u8FupQhbCp3x/lSt4w
=8IkU
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

How do LockOutRealms work ?

[Sreyan Chakravarty]

I am confused with the functioning of LockOutRealms in Tomcat.

My questions are as follows-:


   1. Say user at IP 10.10.10.1 has reached the maximum number of invalid
   login attempts and is locked out. Now say a user from 10.10.10.2 attempts
   to login, will Tomcat stop him too since he is trying to login for the
   first time ? If not then how does Tomcat keep track of users that are
   locked out ? Via there IP's ?
   2. When a user is locked out what message is displayed ? Can I display a
   custom HTML page when a user has been locked out ? In other words how much
   control do I have over the lock out process and what error messages are
   shown ?