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