nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Announcement: Bitbucket Cloud account password usage for Git over HTTPS and API ending March 1, 2022

David Dansby

Hello Bitbucket Cloud users!!!

Update August 2025

Please note that Bitbucket Cloud app passwords are also being deprecated:

New app password creation will be disabled on September 9th 2025.
Existing app passwords will cease to function on June 9th 2026.

App passwords will be replaced by API tokens. Please check the API tokens documentation on how to create and use API tokens for Git operations via HTTPS and API.

You may have recently received an email communication or read our blog post announcing that beginning March 1, 2022, Bitbucket Cloud users will no longer be able to use their account passwords when using Basic authentication for Git over HTTPS and the Bitbucket Cloud REST API.

So, we wanted to take the time to inform the Bitbucket Cloud community of further details regarding this change and provide a FAQ (Navigate to the bottom of this post to jump directly to the FAQ section).

Important Notes (please read)

This does not impact those using an SSH key to authenticate with Git.
There is a known issue with Sourcetree for Windows when users update their connected Bitbucket Cloud account to use their new app password. Please visit our Sourcetree community post for more details and how to resolve the issue.
App passwords do not support email address as a username for authentication. So, some user's Git remote URLs using their email address will need to be adjusted so that they use their Bitbucket Cloud username instead, like so:

From Git remote URL using email address:

https://[email@email_domain.com]@bitbucket.org/[workspace]/[repository].git

To Git remote URL using Bitbucket Cloud username:

https://[bitbucket_cloud_username]@bitbucket.org/[workspace]/[repository].git

Why are we making this change?

The removal of account password usage for Basic authentication when using Git over HTTPS and/or the Bitbucket Cloud REST API is due to Bitbucket Cloud's ongoing effort to align with internal infrastructure and improve Atlassian account security. App passwords are substitute passwords for a user's account and are designed to be used for a single purpose with limited permissions.

By replacing the usage of account passwords with app passwords for Git over HTTPS and/or the Bitbucket Cloud REST API, we are able to improve account security given the fact that app passwords are single-use, have limited permissions, and can be easily and quickly revoked.

You can find more details about the various privilege scopes for app passwords in our documentation.

What effect do these changes have on me and what do I need to do?

Main Functionality Effect

Beginning March 1, 2022, you will no longer be able to use your account password when using Basic authentication with Git over HTTPS and/or the Bitbucket Cloud REST API.

Other functionality affected

OAuth 2.0

Furthermore, it will no longer be possible to perform the OAuth 2.0 Resource Owner Password Credentials Grant (4.3) flow. Bitbucket Cloud still supports the remaining three OAuth 2.0 (RFC-6749) grant flows, plus a custom Bitbucket flow for exchanging JWT tokens for access tokens. More details about accepted OAuth 2.0 flows can be found in our Bitbucket Cloud documentation.

3rd-party tools

If you have saved your credentials (i.e., username and account password) in a credential manager such as Git Credential Manager (GCM), Windows Credential Manager, OS X Keychain, or some other third-party application, then you will need to update them with an app password before March 1, 2022, in order to continue using Basic authentication with the Bitbucket API and/or Git over HTTPS without disruption.

Two-Step Verification (2SV) recovery code retrieval

Bitbucket previously allowed using a combination of the SSH key and password to retrieve a two-step verification (2SV) recovery code. This will no longer be supported beginning March 1, 2022. Users with 2SV enabled should visit their personal settings and securely save or write down their recovery codes to avoid a 24-hour lockout in case of a lost or stolen 2SV device.

FAQ

We have an integration with a 3rd-party application, such as Jenkins. Do we need to update anything?

If you are using an app password or SSH Key for authentication from a 3rd-party application such as Jenkins to connect to Bitbucket Cloud, you do not need to make any changes. However, if you are using your account password for Basic authentication to connect to Bitbucket Cloud, then you will need to update it to use an app password instead.

Does this impact our Jira Cloud integration with Bitbucket Cloud repositories?

Jira Cloud integration with Bitbucket Cloud will not be impacted by this change.

How can I recover a Two-Step Verification (2SV) recovery code using SSH?

This will no longer be supported beginning March 1, 2022. If you do not have access to your 2SV recovery codes and do not have access to your 2SV device, then you will have to request a 2SV email recovery by following these steps:

Attempt to login into your account. This will take you to the 2SV login page.
Select the Don’t have a key? link at the bottom right of the 2SV login page. This will take you to the 2SV recovery code login page.
Next, select the Forgot code? link at the bottom right of the 2SV recovery code login page.
Finally, select Send recovery email. This will initiate the 2SV email recovery process to assist you in gaining access to your account again.

To help avoid any further disruptions, remember that this will create a 24-hour delay in getting access to your account.

Does this change have any impact on my existing integration with a 3rd-party application using OAuth 2.0?

This change should not impact integrations with 3rd-party applications using OAuth 2.0.

As a workspace admin, how can I verify if any of our users are using Basic authentication for Git over HTTPS?

There is no functionality within Bitbucket Cloud to allow workspace admins to identify what authentication method each member of the workspace is using for Git transactions.

Does this change have any impact on my existing configuration with SSH-based Git operations?

There will be no impact on SSH-based connections.

Does this change have any impact on my configuration with Bitbucket Cloud with tools like Eclipse, PyCharm, Sourcetree, etc.?

If you are using the HTTPS protocol for Git operations, and it was configured using your Atlassian account password for Basic authentication to connect to Bitbucket Cloud, then you will need to update your configuration to use either an app password. You can also switch to the SSH protocol by generating and uploading your SSH public key to your Bitbucket Cloud profile.

We are using Google Cloud Source Repositories to mirror our Bitbucket Cloud repository as outlined in their help guide. Will this integration be impacted by the removal of account passwords for Basic authentication with Git over HTTPS and the Bitbucket Cloud REST API?

This functionality should not be impacted. However, Google Cloud could request that you re-authenticate yourself at any time.

Happy coding,

The Bitbucket Cloud team

Comments

Nikki Zavadska _Appfire_

Thanks for the heads up! 🙏

심영경

작업할때의 프로토콜의 사용지침서에 따라 에러가 날시 대처기술이 있을까요~???^^

svenbader

It stopped working today or are the servers down? I cannot commit anything.

David Dansby

@svenbader this change has not been implemented yet, so the issue you are experiencing is completely unrelated. Committing on your local machine/directory is unrelated to Bitbucket Cloud. Are you trying to commit in Bitbucket Cloud itself or your local machine/directory? We have not seen/heard of any issues with committing on Bitbucket Cloud itself.

I also tried with some of my personal repos myself and didn't experience any issues committing within Bitbucket Cloud. If you are having issues committing on your local directory (i.e., before you push to Bitbucket Cloud) then the issue is most likely to related to git on your local machine; there could be a number of reasons for such an issue.

svenbader

@David Dansby I commited to bitbucket cloud, I added the repositories to phpstorm using the https-URL: https://myusername@bitbucket.org/myusername/myrepository.git years ago. The error message was "Push failed, remote: Invalid username or password". Now it is working so maybe it was a temporarily problem on my machine or someone of your team is testing the changes for March1st ;-)

David Dansby

@svenbader I can say with 100% confidence that the issue you experienced is completely unrelated to this upcoming change. Also, to clarify, the issue you experienced is related to pushing, not committing. Furthermore, testing is never done on production servers.

Based on the error message you provided and without knowing more, I would surmise the most likely issue is that your password was entered incorrectly; I personally have this happen to me all the time on my local computer because I always type my password wrong hah . However, I'm glad you got it working without any further assistance

Let us know if you experience anything else weird and/or related, especially after March 1.

Happy coding,

David

artemcs

Should I store my app password on an arbitrary computer? It is not safe. Why are you forcing us to do this?

Please explain if it is possible to continue using Attlassian Git safely on the command line with my password?

beef623

Migrating off of Bitbucket because of this. It's been a fun 9 years, but I need to be able to access my repos with a static typable password. It isn't feasible nor secure to add my ssh key on all of the machines where I may be committing a change and the app passwords are a nightmare to try to type much less remember, not to mention you can only see them once. If I could set my own app password maybe, but as it stands it's unusable for me.

rhinor

Regretfully this has been a massive headache for me this month as there is something in my git credentials that prevents the revision.

I submitted my issue to Stack Overflow - https://stackoverflow.com/questions/71269362/ - without success, perhaps you could advise what I should do, if you succeed I can post this on Stack Overflow in case someone else encounters the same problem.

Rhinor

------

David Dansby's suggestions below resolved the issue. Many thanks.

David Dansby

@rhinor the answer in that StackOverflow discussion is along the right lines, so I'm curious what is still the issue. You may be missing a step or too (the answer provided in there wasn't the most detailed).

I see that you are using a Macbook, so the following is trying to closely align with Mac OSX.

Can you please tell me if, when you push/pull from Bitbucket Cloud, your terminal is prompting you to enter your password? If you are not being asked to enter your password/credentials then I imagine you are not seeing the terminal prompt you for your password for authentication, because typically a lot of OS systems store your credentials after the first successful use of the password for that specific Git remote URL.

If you are using a Mac then your password is most likely being stored in its credential manager, OS X Keychain. To determine what credential manager Git is using to store credentials/password you can follow use the steps in the Cause section of the following Bitbucket knowledge base post to find out where they are being stored (this is similar to the answer in the StackOverflow thread):

https://confluence.atlassian.com/bbkb/why-am-i-not-prompted-for-password-when-pushing-or-pulling-to-my-repositories-in-bitbucket-cloud-via-https-800293400.html#:~:text=The%20most%20likely%20reason%20for,c)%20for%20a%20specific%20repository.

Once you determine where your credentials are being stored you can do 1 of 2 things:

First, please ensure you create an app password.

This is the step I personally prefer: determine where your credentials are being stored in the Cause section of the link I provided above,
1. Remove those stored credentials.
  1. For example, on my Macbook, my creds are being stored in Keychain Access app which is the app associated with the git config credential.helper osxkeychain.
2. In this case, the next time you go to push/pull to Bitbucket Cloud from your terminal again you will be prompted to enter your password.
3. Enter your new app password and then the credential manager Git is using should store this app password
4. Next time you push/pull you should no longer see the error messaging and will not be impacted the change on March 1, 2022
I personally do not prefer this because then you have to enter your password every single time you push/pull: use the Resolution section in the support link I provided above
1. Unset the credential manager Git uses.
2. Next, time you push/pull your terminal will prompt you to enter your password.
3. Enter your app password going forward to avoid seeing the error message, and importantly to avoid being impacted by the change on March 1, 2022 going foward.

Please let me know if this helps.

Javier Davalos

I followed the instructions. When I'm trying to enter the app password on sourcetree it says:

Failed to get user details for user [my user]

you do not have permission to access URL 'https://api.bitbucket.org/2.0/user. The request returned with the statuts code 'Unauthorized'

What should I do?

Account settings on sourcetree:

Hosting service: Bitbucket

Protocol: HTTPS

Authentication: Basic

Username: my username

Mrunmayee Prakash Shirodkar

I push my changes to AWS server using basic authentication over AWS SSH. Do I have to now use the app password instead?

strafton

How is it I am just getting this email now, less than 24 hours before these changes are being applied?? I understand the reason but the drop everything and do this right this second is absurd!!

Kevin Matlock

This change appears to have broken my Sourcetree install. I've followed the information on how to create a temp application password, and have added this to the authentication details in Sourcetree's options. The app shows "authentication OK", yet when I try to interact with my repo I'm seeing a "SSL certificate problem: unable to get local issuer certificate".
Atlassian - have you fully vetted the changes to this?

UPDATE: I'm seeing that firewalls appear to be blocking some elements in this new authentication mechanism. I found that disabling mine does indeed allow my Sourcetree install to once again talk to Bitbucket Cloud. Not sure what the internal reasons are for the breakage, but this might be necessary workaround.

David Dansby

@beef623 I can personally relate to your frustration but we (i.e., Bitbucket Cloud) believe this change is necessary for the overall security of our users in order to protect against credential scanning attacks.

TBH, I have some of the same concerns/annoyances as you with regards to dealing with app passwords for my personal Bitbucket Cloud account. This may not be the best resolution for your situation, but you could use a password manager to store your app password so you don't have to memorize it. It's what I personally use. It's not a perfect solution, but it works pretty well for me; maybe it can assist with your concerns as well.

Best,

David

artemcs

You are not developer, and not admin too.

It is so stupid. I need access to my repositories from dozens of different computers. I need HTTPS access.

David Dansby

@Kevin Matlock thank you for the update. I was actually just about to respond. We haven't experienced this issue on our side testing with Sourcetree. I'm glad you got it working. To clarify, the Firewalls you reference on specific to you (or your company), correct?

Kevin Matlock

@David Dansby yes it's a client-side firewall product that my company has deployed. I suspect it's just a matter of white-listing Sourcetree for this necessary network traffic, which I'll work with our network admins on. I felt it was worth mentioning in case others have a similar sudden breakage just to understand the root cause.

David Dansby

@Kevin Matlock definitely agree! We are grateful for updates on resolutions you have found as it can definitely help others that may be experiencing similar issues. Thank you very much for that.

gileadAutomation

-- 03-Mar-2022 Final UPDATE and SUCCESS!

For those that are working on Linux servers via HTTPS, I finally got the app password to work. The first clue was made by @Alexander Higgins so thank you for your comment about username and checking what this is set to in your profile.

"HTTPS - I was previously able to connect using the email associated with my Atlassian account which was `firstName.lastName@myCompanyDomain.com`. This does not work for app passwords with https . You need to use the username which shows in settings under your Atlassian account."

Even after I updated this, I was still getting the warning. This is because the credential manager has cached your old password. I tried rebooting my server, but it's still cached some place else beside memory and beside the config files. So if you clear your passwords at all levels explicitly by:

git config --local --unset user.password

git config --global --unset user.password

git config --system -unset user.password (might need to be root via sudo)

It will prompt for the new app password and the warning message goes away.

You can restore using your new app password by

git config --global user.password "<generated_app_pwd_here>"

So it seems that they are giving us a few extra days passed Mar 1 to fix this on our side and the warning DOES go away if you fix it right!

Thanks,

David

--- 02-Mar-2022 UPDATE ---

It's now 02-Mar and I did another test check-in and get the same message. So this message is not conditional on the date and hopefully not on the proper use of an app password.

@David Dansby - can you briefly comment on the state of this change? Has the use of login passwords gotten extended with the pending issues people have listed here? If we still get this message on a check-in, are we still doing something wrong or will it always show even if it's accepting the app password.

--- 01-Mar-2022 UPDATE ---

It's now 01-Mar and after doing a test check-in, I get the same message. I'm wondering if it's all working, but the message is still displayed in error, especially since I updated my stored password yesterday to the new app password. It would be nice to hear from the support team today Thanks, David

---------------------------------------------------

Hi!

I followed the instructions to create an app password and then updated the password in my Git Credential Manager in my RedHat Linux client by entering:

git config --global user.password "<generated_pwd_here>"

but I'm still getting the below notice when I push a change to my repository.

What else do I need to update?

Thanks,

David

remote: You are using an account password for Git over HTTPS.
remote: Beginning March 1, 2022, users are required to use app passwords
remote: for Git over HTTPS.
remote: To avoid any disruptions, change the password used in your Git client
remote: to an app password.
remote: Note, these credentials may have been automatically stored in your Git client
remote: and/or a credential manager such as Git Credential Manager (GCM).
remote: More details:
remote: https://bitbucket.org/blog/deprecating-atlassian-account-password-for-bitbucket-api-and-git-activity

GaijinFizz

That would have been nice to notify us at least a week in advance... just got an email today about that.

Jakob_tu2qqc

What about Git LFS? AFAIK, it always uses http to fetch files. It seems that it does not use any password, so the security is probably purely URL-based.

simone_gasparella

Hi!

I followed the instructions to create an app password and then updated the password in my Git Credential Manager by entering

git config --global user.password "<generated_pwd_here>"

but I'm still getting the below notice when I push a change to my repository.

What else do I need to update?

Thanks,

Simone

Renee Dubuc

@David Dansby Where can I find documentation about the permissions for an app password?

How do I know what permissions I need for Git Bash?

app password permissions.PNG

Marc Reig

I work with GitHub Desktop app. I love it and do not mean to change it.

I've just wrote this post on Isuees list to GitHub Desktop:

https://github.com/desktop/desktop/issues/14035

They closed it saying; not a problem from us.

Sumarizing:

I've a BitBucket account with some personal projects created by me. Those sync on my PC and correctly managed from GitHub Desktop. They sync OK today with my BitBucket account user/pwd pair.
But I've some sync projects on same PC where I'am a contributor (not my projects, but other fellows ones), but I've ADMIN rights on those projects.
Those are the ones that do not sync. If I refresh, it gives me an Authentication Failed and no user/pwd possible works. I've created an APP Pwd for all user accounts, with all permision checks marked. Full rights. Used those tokens to login and nothing.
My app password works on my projects as my Atlassian user/pwd pair do. But shared projects simply do not sync. Keep asking for credentials.

Any ideas?

Alexander Higgins_rhu9aj

Let me bump the other comments about receiving a warning email 24 hours before and only seeing it the day off.

Now, I have I created a new app password and set it in our Team City Server Self Host and it is complaining it is unauthorized.



Test connection failed in SalesReports / Build
org.eclipse.jgit.errors.TransportException: https://bitbucket.org/{projectName}/salesreports.git: not authorized

Even worse we have to update credentials on our build servers, agents, and all custom CI/CD apps integrated into our pipeline and all client machines that have GIT install.

For what? I don't see any security benefit here. In fact it is the opposite. App password a statically generated 20 character alpha-numeric with NO special characters. Furthermore, they are static and cannot be changed, in the event they are eventually compromised, and they will be.

The permissions also cannot be changed and since many people will be repeatedly use them throughout their organization, which increases the possibility end users will store plaintext password stored in multiple locations from each client that needs the credentials, like in config files. Also since the permissions are immutable once created default choice will be to give the app password full permissions to everything.

Let's not even take about how they won't be forward compatible with new features. Instead user will be directed to recreate new app password with the new permissions included.

Alexander Higgins_rhu9aj

Niether the APP password or SSH setup are working to authentication from Team City .Both fail with

not authorized

The SSH instructions state the key must be confirmed by email but that hasn't come after trying to create two different keys. (Yes my email is configured, I get Atlassian emails including notifications about this thread).

Meanwhile Settings say the SSH key was never used despite numerous not authorized connection attempts and the app password has no timestamp for last access time.

Marc Reig

Not the same problems as @Alexander Higgins

but really close on desesperation!

It makes no sense what you have done here. And if I achieve to re-sync shared projects, still to re-config all CI/CD environtments, Github desktops, etc...

I think you've rushed on here, and made it wrong having to rollback.

Don't understand why I can keep using my Atlassian user/pwd pair to sync my projects but don't the shareds. And full rights APP Password for me, does the same, and do not work on shareds too. But even repository author of those shareds created an APP Password and those are not useful too! Those credentials (atlssian pair and app password) do not let you sync those shared projects!

I've tried to re-CLONE (via CMD) on a test folder on my desktop with MY atlasian pair credentials, introduced when promted, one of those shared projects on the DEVELOP branch, and everything work fine! So they work for clone as it seems...

David Dansby

@Marc Reig have you tried any Git ops (i.e. push/pull/clone) without GitHub Desktop (just using terminal instead) for those shared projects to see if it works fine without GitHub Desktop?

David Dansby

@Renee Dubuc you can find more details about app password perm scopes in our API documentation. These are the same perm scopes used for app passwords.

https://developer.atlassian.com/cloud/bitbucket/bitbucket-cloud-rest-api-scopes/

I've added this to the main post as well.

Thank you.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud

bitbucket-administration

development

atl-orange

bitbucket-development