User account getting locked

Question

While using source tree with embedded git or system git, user stores their credentials in the preferences of source tree or in keychain/credential manager depending on the OS. Now when their cloud credential gets changed and if they forget to change the local stored credentials, Source tree sends multiple request to bitbucket without prompting the user to enter correct credentials after the first failure which gets their user account locked from the corporate system to avoid brute force attack.

Due to above mentioned reason our company's IT Team is denying the access to use source tree and source tree application has been blacklisted in our company.

Following is the explanation I received from our company's IT Security team for blacklisting source tree application and not allowing company developers to use source tree:

"Good applications should tell you that you entered the incorrect password.  SourceTree does not, and silently retries without notification to the user until the lockout occurs (and even then, I am not sure it tells you your account is locked out, it just keeps trying the bad password, so it would continue to cause lockouts).  That is a denial of service vulnerability."

Expected Resolution from IT Team:

Source tree should only send one request to bitbucket ui to confirm if the credentials are valid and if credential are invalid then prompt user to enter correct credentials or as them to change their local cached credentials before sending another request to bitbucket.

Can I request Atlassian to look into this issue.

Sang Jung · Answer

There are multiple sourcetree questions, discussions, bugs regarding this topic.  Here is one such bug, vote up and comment and maybe, just maybe something will be done https://jira.atlassian.com/browse/SRCTREE-6916

shalinbanjara · Answer

Hi Mikael,

Thanks for the feedback, its much appreciated!

I never faced this issue before with source tree. I generally use the system git with sourcetree and me being on mac - store my credentials in keychain. I ensure to set my sourcetree preferences to refresh remote updates to 60 mins. This ensures that source tree will not send frequent queries to check remote updates. Also I ensure to close source tree before changing my bitbucket credentials and delete local cached credentials from keychain immediately after changing my bitbucket credentials. This way I ensure that source tree using system git does not send request to bitbucket with incorrect credentials which may result in user account getting locked.

With the recent change in IT Security Policies within the Company I work for, this has become an issue they are stating that for novice/new employees by default would not know a workaround and the current behaviour of source tree will result in user account getting locked because source tree is sending multiple request to bitbucket in-spite of getting access denied on the first request as shown in the screenshot. They have verified that this happens even when using builtin git of source tree.

The IT Security Team is expecting following to be fixed within source tree app:

* Source should not send multiple request to bitbucket if the first request return back access denied error.
* On receiving the access denied error for the first time, source tree should prompt the user for new password flagging that the current credentials stored within source preferences or keychain/window-credentials are incorrect depending on the use case.

Due to above mentioned reason the IT team within our company has black listed source tree application and enforcing developers to not install and use source tree. They won't whitelist the application until the expected resolution is not applied to source tree.

Mikael Sandberg · Answer

Hi @shalinbanjara,

Welcome to Atlassian Community!

I ran into this issue at my previous job too, and it is not the credential manager within Sourcetree that is causing it, on Windows it is actually the Windows Credential Manager that is the culprit and how Git is sending requests. The way we solved it was to turn off the credential manager and either rely on the one builtin into Sourcetree or use SSH. The beauty with SSH is that you don't have to deal with passwords and what to do when you change it.