The user 'xxx' is required to answer a CAPTCHA elevated security check. Failure count equal

Andreas Lorz

Hi everyone,

we encounter following jira behaviour. We have a service user which does some REST API stuff. 

From time to time it happens that user will be locked for authentication. Even though passwort of the service user never expires and service user is only used for this porpuse (no other and/or manual usage).

Oberservation 1) User will be locked (or at least something happens here), even though authentication might be right

After this, I can see in log. 

The user 'xxx' is required to answer a CAPTCHA elevated security check.  Failure count equals ...

I thoght this mark a situation where user is locked and can't login anymore. However in another custom log it states that user can still execute stuff.

Observation 2) User still do sucessfull requests via API even it seems that it is locked or CAPCHA is required.

For me this does not match with the jira log.

Any hints on this?

Can somebody explain if I understood CAPCHA behaviour and user locking right?

I thoght that if user has e.g. 3 failed attemps, the user will be locked and user isn't able to login anymore till admin unlock the user. (Maximum Authentication Attempts Allowed)

And what's the deal with CAPCHA here?

User is from conected AD. 

 

Thanks in Advance.

Andreas

Radek Dostál

Unless you can reproduce this by e.g. hooking up a job that does X requests per minute, or if there are not any other users reporting authentication problems, then it's most likely that code behind that user is faulty and is not supplying the credentials in some calls.

Captcha is there to help prevent brute force / automated attacks, as to how effective that is in practice with all the AI stuff, probably less, but it sure helps against most of brute force hotshots so I wouldn't disable it. You can't fill captcha over REST, you need the actual html page, so it's still plenty useful. Most importantly though, captcha is not the root of this problem.

I still suspect the code is broken, or, there is a problem in ldap where it fails to authenticate the user for some reason, but I'm not that familiar how an ldap/ad could fail to authorize a user intermittently, that sounds very unlikely to me.

The other thing is, the user should not be using any credentials at all, ideally they should be using personal access token which does not incur any ldap password verification:

 # https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html

 

Is PAT a viable path? That way you can disregard any issues with ldap. Still though in my view I would go through the code and/or debug the calls it makes to see where there is something unusual, especially the first time it gets a 401/403 error, which part of the code, which endpoints.