Environment
Access Manager 4.4
Identity Server
Captcha enabled on name/password class
Situation
Access Manager 4.4 Identity (IDP) server setup with captcha enabled and everything working fine. Users that enter invalid passwords X number of times (where X is the value set in captcha config) will get challenged via captcha as expected.
After upgrading to NAM 4.4 SP1 (4.4.1.0-148), users submitting invalid passwords X times on methods with reCAPTCHA enabled get the following warning on the browser instead of captcha challenge:
"This site key is not enabled for the invisible captcha.”
After upgrading to NAM 4.4 SP1 (4.4.1.0-148), users submitting invalid passwords X times on methods with reCAPTCHA enabled get the following warning on the browser instead of captcha challenge:
"This site key is not enabled for the invisible captcha.”
Resolution
Enable invisible captcha on Google for this IDP server host, and reconfigure the captcha configuration to reference the Google invisible captcha setup just done.
With NAM 4.4.1, the entire recaptcha was redesigned to
a) handle security limitations with captcha v2 and BOTS and
b) improve the user experience where users click a single button instead of having to do the recaptcha everytime. If the recaptcha thinks your are a robot then it presents the user with images to select otherwise it doesn't and remains invisible, logging you in.
The old captcha feature as implemented was of little use as it tracks how many failed logins occured on an exiting session. If you tried with different sets of credentials over different sessions, as a BOT would, you could get you around the issue unless recaptcha was set to 0.
With NAM 4.4.1, the entire recaptcha was redesigned to
a) handle security limitations with captcha v2 and BOTS and
b) improve the user experience where users click a single button instead of having to do the recaptcha everytime. If the recaptcha thinks your are a robot then it presents the user with images to select otherwise it doesn't and remains invisible, logging you in.
The old captcha feature as implemented was of little use as it tracks how many failed logins occured on an exiting session. If you tried with different sets of credentials over different sessions, as a BOT would, you could get you around the issue unless recaptcha was set to 0.
The new implementation will trigger on the headless bots and only trigger if a bot is detected.