ConfirmEditTriggersCaptcha allows the use of arbitrary logic to determine whether the captcha should be shown, but it has several shortcomings for use during authentication:

• The user who is triggering the captcha (which, during login, isn't the same as the session user) isn't passed to the hook handler
• There is no way for the hook handler to tell the user what's going on - some way to return a message explaining why the captcha is shown would be nice
• The log message for hook-triggered captchas in CaptchaPreAuthenticationProvider is slightly different from counter-triggered ones, but not in a particularly helpful way. The log message should just clearly say that a hook was involved.
• The captcha control flow during authentication is very confusing. The hook is called three times: from getAuthenticationRequests() on GET when rendering the login page, from getAuthenticationRequests() when processing a POST, and from testForAuthentication() right after that. If the hook returns different things for those three calls, the user might get locked out (because testForAuthentication() expects a captcha value but the captcha was never shown to the user, or the authentication request to store it into isn't there), or the captcha might be shown but then not verified. For some counter-related situations the ConfirmEdit:loginCaptchaPerUserTriggered session flag is used to ensure consistency; this should be extended to all situations.