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-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é.