Re: How do LockOutRealms work ?

[Ludovic Pénet <l....@senat.fr>]

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 <ch...@christopherschultz.net> 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 "zzzzzzzz" 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 "zzzzzzzz" 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-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org

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