Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

revoked app passwords are still active


When working from places like corporate enterprise network, In order to avoid leakage of my main Bitbucket/Atlassian password, I use Bitbucket "app passwords".

When my job is over, I revoke the password.

However, I noticed that even if I revoke an app password, it remain usable.

For exemple, I am still able to clone a repo after revoking the associated app password.

Please note, that I use Windows manager-core.


- Step 1 : delete any user entry in manager-core : with `git credential-manager-core erase`

- Step 2 : create an app-password within Bitbucket UI

- Step 3 : Clone with this password.

- Step 4 : revoke this app password

- Step 5 : delete local repo and try to clone again : it works !

Actually, i should not work as it has been revoked.

I thought, I'd have to wait some time for revocation to take effect : 24h later, i can still clone with thre revoked password.

Have you encountered a similar behaviour ?

Am i doing something wrong ?

2 answers

OK, I have been investigating a bit further on this issue and doing a bit more testing.

Actaully Theodora command to use app-password is the right one :

git clone

Indeed : in order to use app-passwords, it is mandatory to write the password on your command.

On my side, I was using :

git clone

In fact, I tend to dislike to write the password in the terminal in clear. I prefer to not do so & wait for a obfuscated passwd field to be displayed.

If you perform this, as i described in my response to Theodora :

- a Bitbucket pop-up will pop and ask for the app-password.

- then it will open a webpage inviting you to login to Bitbucket with your main account/password.

Finally, if you do this, you might think Git will use the app-password when interracting with Bitbucket. But no : it uses your main credential !

This why revoking the app-password won't change anything.

Well, my bad. However lots of folks may dislike writing credential in clear in the terminal and then be brought to another authentication route they do not expect.

Hi @stockersky,

I suggested using the clone command with the app-password for testing purposes only, in order to confirm whether the app-password is working not, I'm sorry if that wasn't clear. I wouldn't recommend using it in the clone url every time you clone a repo.

I checked our logs for clone events performed by your Bitbucket Cloud account during the last 7 days:
- some of these clone events on December 10th have as authentication method app-password
- the rest of the clone events have as authentication method OAuth
- I don't see any events with authentication method password

It looks that the credential manager is prompting you to trigger OAuth authentication.

If you're using the following credential manager:

I can see there is a setting available for authentication modes when using Bitbucket:

Do you see any setting for credential.bitbucketAuthModes when you run git config -l ?

You can try setting this to basic only and see if you are then prompted to enter a password.

If you face any issues or have any questions about why you are being prompted to trigger OAuth, I would also suggest raising a question in this project's issue tracker.

Kind regards,

Hello @Theodora Boudale 

I re-installed the last version of Git (2.34.1) and made sure to select the "Git credential manager core".

I then issued the command as advised:

git config --global credential.bitbucketAuthModes "oauth,basic"

OK, this config is now in git config.

I cloned again without providing the passwd :

- a popup asks for the app-password (note : I cannot write a wrong password here. It needs to be the right app-password.)

- I am then invited to provide my Bitbucket login/passwd :


==> I quited the last step by closing the window.

==> then another popup came asking for a passwd : I provided the app-passwd and the repo got cloned :


Actually, I realized this last test with "Windows Terminal" and this last popup was obvious on the screen.

But on my previous tests, I used "VSCode Terminal". The same purpose popup was issued within VSCode, in the command pallette. Sorry, I did not noticed it.

To sum it up :

- first popup to input app-password (clearly managed by Bitbucket)

- then routed to Oauth

- if refusing Auth --> another popup (managed by Git itself) ask for app-passwd

-  cloning

Can you reproduce this behaviour ?

0 votes

Hi @stockersky,

I have been unable to reproduce this behavior, and I would like to ask a few questions so we can figure out why this is occurring:

1. Are you using a Git GUI client to clone, and if so, which one? Or are you using Git Bash, or another terminal?
2. Do you get asked for a password when you attempt to clone, in both steps 3 and 5?
3. Could you perhaps try cloning with the following command before and after revoking the app password?

git clone

and let me know if you see the same behavior?

Replace Bitbucket_username, app-password, my-workspace, and my-repo with the respective values for your use case

Kind regards,

Thanks for taking care of this issue Theodora.

1. I use Git Bash.

Here is the ouptut of `git config -l` showing the credential manager :


Before performing this test, I flushed everything from Bitbucket in Windows Credential Manager (

No credientals left : I cannot clone anymore without authenticating. Good : this is the expected behaviour.

Let's perform the test now.


2. I clone using the command you supplied without the password field :

git clone`

Then I get an Atlassian Pop-up asking to fill the password.

Once, this is done, I get redirected to the Atlassian login page (However, I did not activated the 2 factors auth) : here I must fill my main login (email)/passwd (what the point ???)

Then, the repo is cloned


3. I revoke the password and try to clone again : I am not asked for any new auth crediential. It clones.

This is definitely not the expected behaviour.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events