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 <ma...@apache.org> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
