BUG: Sourcetree app is reliably kicking my app password session
Asked by mai_il_2011:

The new app passwords are not working well at all. The Sourcetree app keeps killing my session on a weekly basis. This never happened with the normal user account passwords.

Please provide a fix for this or tell me how I can make sure the sessions aren't killed every week. I have literally had to create a new app password every single week.


Answers:
author: Mukesh Kumar
body: Hello [@mai_il_2011](/t5/user/viewprofilepage/user-id/2304003) ,

Bitbucket does not expire the app password ([more info](https://community.atlassian.com/t5/Bitbucket-questions/Does-a-quot-bitbucket-quot-app-password-expire/qaq-p/1958337#:~:text=based%20on%20the%20following%20guide,and%20it%20doesn't%20expir)).

However when the user uses the authentication type as **Basic**, Sourcetree uses the app password created by the user in Bitbucket. Sourcetree stores those credentials through Windows Credential Manager.

Credentials in the Windows Credential Manager can get erased due to following issues:

* If Git believes the credentials failed to grant proper authorization to do whatever Git was attempting to do, it asks **git-credential** to erase the stored credentials. The **git-credential** process then invokes **git-credential-manager** to delete the stored credentials ([more info](https://github.com/microsoft/Git-Credential-Manager-for-Windows/issues/58)).
* Windows Credential Manager loses passwords ([more info](https://superuser.com/questions/1568383/log-deleted-credentials-from-windows-credentials-manager)). Microsoft has provide a fix for this issue ([more info](https://answers.microsoft.com/en-us/windows/forum/all/systemwide-password-amnesia-v2004-build-19041173/232381f8-e2c6-4e8a-b01c-712fceb0e39e)).

To avoid this issue we strongly recommend using **OAuth** authentication over **Basic** authentication ([OAuth setup guide](https://blog.sourcetreeapp.com/2017/02/10/oauth-support-and-ssh-key-generation/)).

OAuth does not use app passwords at all. It is more secure and easy to setup than Basic authentication.

Regards,

Mukesh Kumar

comments: author: mai_il_2011
body: Why did Windows not expire the sessions that were created with normal passwords that you forced us to stop using? Can you please explain why we were forced to switch to app passwords if people are going to be told by your support staff via email to just keep the passwords stored in plain text? Why create app passwords if they don't work as YOU indented them to (IE: Have sessions that don't expire)? I was able to use my normal password up until recently and this is honestly the most frustrated I've been in a long time because you refuse to help sort out YOUR BUG. I've been going back and forth with you all for a month now just to essentially be told by you here that "It's not our fault, it's Windows' fault, we recommend you don't use our feature that we forced you to switch to." Do you realize how that sounds to us as users? It's completely illogical. Furthermore, Microsoft's "fix" article you referenced is from 2020, well before you forced us to switch to app passwords. If it's a problem before you force us to switch, I'm sorry, that bug in on YOU. NOT Microsoft. Please provide a viable solution or fix to your product's bug. If credential manager works a certain way, then you adapt. You don't jerk me around for a month after forcing me to start using a feature I never asked for.


author: Mukesh Kumar
body: Hi [@mai_il_2011](/t5/user/viewprofilepage/user-id/2304003),  
This is how Git Credential Manager works:  
Git Credential Manager to attempt to authenticate and if due to any reason like internet issues, corporate firewall and policy or anything else if authentication fails then Git Credential Manager deletes the stored credentials. **This is independent from Sourcetree**.  

**Below is the link of the same issue where people are talking about same issue and they are using Git by command line not by Sourcetree.**  
**<https://github.com/microsoft/Git-Credential-Manager-for-Windows/issues/58>**  
(I have two different build agents, one for production, the other for development. On both boxes, I have Git Credential Manager for Windows installed. Via the git command line, I enter my username and password the first time and the application stores it into Windows Credential Manager for future use. This all works perfectly... except when a few days later the credential disappears from the store and all my processes that depend on that break. I have looked through the event logs, TechNet, this repo, and other various tech forum and I can't find the root cause of this.  
It only happens with the Visual Studio Online credential. I also have a bitbucket credential stored and it doesn't have this problem.  
Unfortunately, this is inconsistent. Sometimes it will go a week before the credential disappears, sometimes it happens daily.  
For now, I've resorted to manually backing up the credential store and then manually restoring it. Is there something broken between this application and VSO that causes this behavior? The documentation specifically states that it was designed to work with build agents and VSO so it seems very unusual for this issue to continually happen.)  
Since that issue is not under control of Sourcetree, we recommend using **OAuth**for authentication.  
Regards,  
Mukesh Kumar


author: mai_il_2011
body: Can you explain why user passwords worked completely fine? Everything was perfectly fine until you forced us into using app passwords which don't work.


author: Mukesh Kumar
body: Hi [@mai_il_2011](/t5/user/viewprofilepage/user-id/2304003)

<br />

Atlassian account password for Bitbucket API and Git activity has been deprecated to improve Atlassian account security ([more info](https://community.atlassian.com/t5/Bitbucket-articles/Announcement-Bitbucket-Cloud-account-password-usage-for-Git-over/ba-p/1948231)).

Stored credentials from Windows Credential Manager can be removed due various reasons including corporate policy and firewall. Can you please check with your IT team to understand better on how the app password gets removed?

We would suggest trying to use the [**OAuth** authentication](http://OAuth%20setup guide) method instead. It's typically much easier to use and it should authenticate you by walking you through the Bitbucket Cloud login screens with your account password (instead of an app password).

Regards,

Mukesh Kumar


author: mai_il_2011
body: You didn't answer the question at all.... Let me ask it a different way in hopes you answer it this time... Did normal account passwords (which you forced us to stop using) use credential manager in the way app passwords do? I'm looking for a yes or no answer to this.


author: Mukesh Kumar
body: Normal account credentials were not stored in the Credential manager.


author: mai_il_2011
body: Why was a perfectly good technology taken away for an inferior replacement that does not at all work reliably? You yourselves are advising against the very thing you replaced normal passwords with. I understand that you don't have control over the underlying technology you built app passwords on, but if that underlying technology is unreliable, it by default makes the feature you built on top of it unreliable.

Why did you choose an unreliable and unstable technology stack to replace normal user account passwords with? I would like an answer to this.


author: Mukesh Kumar
body: That's the technology available for this purpose.

Atlassian account password for Bitbucket API and Git activity has been deprecated to improve Atlassian account security ([more info](https://community.atlassian.com/t5/Bitbucket-articles/Announcement-Bitbucket-Cloud-account-password-usage-for-Git-over/ba-p/1948231)).

We would suggest trying to use the [**OAuth** authentication](http://oauth%20setup%20guide/) method.


author: Stephen Sifers
body: Hello [@mai_il_2011](/t5/user/viewprofilepage/user-id/2304003),

Stephen Sifers here, Product Lead for Community. Firstly, I want to let you know personally I've reviewed and read through this thread and heard your concern about the change and the problems it is causing you and your team. I hear your frustration around not getting a direct nor acceptable answer and wanted to ensure we give you the best path forward. For your questions around a feature change within our products in regards to passwords.

We had multiple announcements around this change and ensured it was communicated well before the change occurred; please see the following.

* [Deprecating Atlassian account password for Git and Bitbucket API activity (June 29, 2021)](https://bitbucket.org/blog/deprecating-atlassian-account-password-for-git-and-bitbucket-api-activity)
* [Deprecating Atlassian account password for Bitbucket API and Git activity (September 3, 2021)](https://bitbucket.org/blog/deprecating-atlassian-account-password-for-bitbucket-api-and-git-activity)
* [Announcement: Bitbucket Cloud account password usage for Git over HTTPS and API ending March 1, 2022](https://community.atlassian.com/t5/Bitbucket-articles/Announcement-Bitbucket-Cloud-account-password-usage-for-Git-over/ba-p/1948231) (This thread does address some of your questions)

Additionally, while it is unfortunate that you're having your sessions dropped while using an app password, there are multiple environmental variables that could be the cause of this. Mukesh and I are not wanting to blame others but simply stating a matter of fact when applications are installed on client-side devices that are governed outside the control of Atlassian-hosted applications. Other options have been provided to assist with your credential issues, such as [OAuth](https://developer.atlassian.com/cloud/bitbucket/oauth-2/). You may also use an [SSH Key](https://support.atlassian.com/bitbucket-cloud/docs/set-up-an-ssh-key/) as another alternative.

* [SSH Key: https://support.atlassian.com/bitbucket-cloud/docs/set-up-an-ssh-key/](https://support.atlassian.com/bitbucket-cloud/docs/set-up-an-ssh-key/)
* [OAuth: https://developer.atlassian.com/cloud/bitbucket/oauth-2/](https://developer.atlassian.com/cloud/bitbucket/oauth-2/)

If you're unable to implement any of the provided solutions, we ask you to review our [New Features Policy](https://confluence.atlassian.com/support/implementation-of-new-features-policy-201294576.html) to understand how new features and suggestions are processed ([Implementation of New Features Policy](https://confluence.atlassian.com/support/implementation-of-new-features-policy-201294576.html)).

You're also welcome to submit feedback outside of your existing support request at [Feedback for the Founders](https://www.atlassian.com/company/contact/contact-ceos).

I hope the information above provides insight into the changes along with alternatives you may use to find the cause of your credential issues. We have heard your feedback, and we are listening.

Regards,

Stephen Sifers, Community Product Lead


author: Stephen Sifers
body: Hello [@mai_il_2011](/t5/user/viewprofilepage/user-id/2304003) ,

I firstly want to apologize for the run-around and back and forth you've been having to deal with regarding this issue. This is by no means the experience we want for customers. From reviewing your support case I do see the developers are working on reviewing your issue to find a root cause but there is presently no update. Your support case is the best place to receive updates on this issue.

If you're having further issues with this issue please let me know via this thread.

Regards,  
Stephen Sifers