Is it safe to share App Password?

[Bitwise DEVS]

I am the admin/owner of the private repos, I want to invite some colleague to collaborate. I enabled pipelines thus 2FA is required and requires me to setup SSH as well. Now I have two option for them to access and be able to push.

1. Invite them using their generated public key and add it on SSH keys page of this account. Thus they will be using SSH remote URL.

2. Generate an App Password and give an HTTPS remote URL in this format

https://<username>:<password>@bitbucket.org/<username>/<repo>.git

With this level of access

Then they will send PRs by logging in using their invited Bitbucket email addresses.

With this approach I am guessing that it is better to give App password per dev, so if I want to revoke someone access others won't be affected. Is it correct?

[Theodora Boudale · Accepted solution]

Hi @Bitwise DEVS and @Pramodh M,

Please allow me to step into the discussion, summarize some info that has already been provided and explain further a few things.

@Bitwise DEVS Short answer to your questions:

1. It is NOT recommended to add other users' SSH keys to the SSH keys page of your Bitbucket account.
2. It is NOT recommended to give an app password generated for your Bitbucket account to other users.

Both of them pose a security risk. I'll explain below why and what the proper setup should be.

Security risk

Please allow me to explain with an example:

Assume there are two Bitbucket accounts

- account with email email-Admin@domain.com, with Bitbucket username Admin (this is your Bitbucket account)
- account with email email-UserA@domain.com, with Bitbucket username UserA (this is the Bitbucket account of your colleague)

• If UserA generates an SSH key pair in their computer, and you add their public key on the page https://bitbucket.org/account/settings/ssh-keys/ of your account, this user automatically gains access to all repos that your account has access to. They will be authenticating with your Bitbucket account, not with theirs.
• An app password can be used for authentication in combination with the username. If you generate an app password for your Bitbucket account, it can only be used with your username. If you give your Bitbucket username and your app password to another user, they will again be authenticating with your Bitbucket account, and could access all repos your account has access to.

In our logs, we won't be able to track a certain action (e.g. clone, pull, or push) back to UserA, since the authentication will be made with your user.

These logs are not currently visible to admins, but our team is planning to work on adding clone and push events to a workspace's Audit Log, so admins can also see which user has cloned/pulled/push to their repos: https://jira.atlassian.com/browse/BCLOUD-8322

With a setup like the above, when this feature is implemented, you will see all clones and pushes tied back to your user.

The proper way to set up access

You invite/give access to UserA using the primary email of their Bitbucket account (email-UserA@domain.com).

• If you want to give them access to 1 specific repo only, you can invite them from Repository settings > User and group access > Add member.
• Alternatively, you can add them to a User group of that workspace by the workspace's Settings > User groups > select the User group you want to add them to (or create a new one) > Add member.

A user group can have access to all workspace's repos, or you can set its default access to None, and then manually add the user group only to repos you want it to have access to.

In both cases, UserA will need to accept the email invitation that will be sent to their email address to gain access.

Afterwards:

a. UserA can create an app password for their Bitbucket account, and use their own username and app-password to interact with repos you have given them access to.
b. Alternatively, they can generate an SSH key pair and add the public key to their account (not to yours).

In both cases a. and b., UserA can interact only with repos they own or have been granted access to.
If you revoke their access from a certain repo/user group of yours, they will no longer be able to access this repo/repos that the user group has access to.
But they will still be able to interact with any other repos owned by them, or repos owned by someone else where they have been invited.

If anything is unclear or if you have any questions, please feel free to let me know.

Kind regards,
Theodora

[Bitwise DEVS]

This is the best answer, I knew it could be better! Thanks a lot for detailed explanation and giving the correct approach on such case.

[Bitwise DEVS]

@Theodora Boudale  just a follow up question, which is better for them to use? SSH or HTTP? Thanks again!

[Theodora Boudale]

Hi @Bitwise DEVS ,

You are very welcome!

Both SSH and HTTPS provide a secure connection for transferring data, it's hard to say which one is better.

Some users find SSH easier to use because this way they don't have to manage (app) passwords.
Others prefer HTTPS because they find the process of setting up SSH complicated.
They can try both and see which one works better for them.

Kind regards,
Theodora

[Pramodh M]

Hi @Bitwise DEVS 

Never ever share App Passwords!!

Ask them the SSH Public key and add it in your repo to give them the write access, go with 1st Option.

Or you have an option to invite them as well

If you need to restrict the Branch Permissions, you can do it in branch permissions under the settings of the repository

Let me know if you need any clarification

Thanks,
Pramodh

[Bitwise DEVS]

May I know the reason? Since anytime we can limit and remove their access as well with App Password I do not see much problem with it or risk.

[Bitwise DEVS]

And I don't think adding them only as members works, because I already tried it. You still need to add their public key or share an App Password for them to push/pull. Adding them as members only allows them to access the project and create PRs in Bitbucket Cloud.

[Pramodh M]

Hi @Bitwise DEVS 

App Password for one thing is used for Authentication with remote repo or API's

Well, the Secure part depends on how the scope is given if you are okay with your repo being exposed when your App token is shared, that's okay.

And yes, you can revoke it but why manage those access with APIs when you can invite users to the repo itself, right?

To give access to a specific email id or user please go with the user's access option.

And if you need to enforce pull requests, configure branch permissions

Thanks,
Pramodh 

[Bitwise DEVS]

Thanks but like I said, users can't push nor pull with regular HTTPS remote URL when SSH is enabled even after adding them as members with write access. You either ask them their public key and use SSH remote URL or give them App Password to be able for them to use HTTPS remote URL with app password in it.

[Pramodh M]

Okay, I got it. @Bitwise DEVS 

So you need to give them full access to the repo?

Here's the reference.

Give them the Write access as specified here

That should work

[Pramodh M]

FYI

[Bitwise DEVS]

I think the link is incorrect :D

[Pramodh M]

Okay Here's the catch.

They can use the HTTPS URL of the repo, and for authentication let them use their accounts App password, don't share your accounts' App key.

App key is associated with the Account, not the repository.

[Bitwise DEVS]

Are you saying that they can use their own account's App password and use it in my repo? Can you show me sample like a video for me to better understand cause if this is the case then that is really mess and should not be possible. App Password is associated with the account and their access should be based on the allowed permissions upon its creation and limited to what repo is in that account.

[Bitwise DEVS]

Sorry I still don't get what you said "let them use their accounts App password,don't share your accounts' App key". You are implying that someone can use their own app password for my repo to still have access on it then say that do not share my app password. That doesn't make sense since it seems like the actual problem is exposing the HTTPS remote URL thus concerns about exposing my app password no longer matters since they are using their own account's App Password.

[Pramodh M]

They can only use it for your repo, if you give them the access via "Users and Groups access" otherwise no, they can't

Yes, the part where you mentioned the access is based on what access you have given in your repo.

So if you have given the user as Write access, they will have write access, they will only be able to pull or push to the repo

[Bitwise DEVS]

So what is the problem with sharing App Password for HTTPS? If there is a problem why such idea is allowed in the first place? Can you provide a documentation about this concern with App Password? Thanks

[Bitwise DEVS]

App Password seems safe as long as the permissions are correct and it can be revoke anytime. What is the actual risk of doing the second option? Anyway I am likely to use public key for SSH but I am curious with this second option that we have.

[Pramodh M]

When you create App passwords is not to define what the user can do to your repo but rather what they can do to the objects that they have access.

You still have control over your repository on what the users can do, you are giving them the write access that's all. 

Even if they create an App password selecting all the options, your repository will not inherit all the options, because you have not given them the right to do so in users' access settings. Hope this is clear!!

[Pramodh M]

Hi @Bitwise DEVS 

FYI To give more understanding here

Let's say Users A, B, C all create App password with all the selection.

Since you have the control over what these can do to your repos

User A will have only write access

User B will have read access

User C will not have access at all

Is this clear?

Let me know if you need any clarification

[Bitwise DEVS]

Giving write access will give read access as well right?

Now you said

"When you create App passwords is not to define what the user can do to your repo but rather what they can do to the objects that they have access."

But based on my attached image in this question. I am only giving this App Password a read and write access on repositories which I assumed is one of the object that you mentioned and my goal is for them to be able to push and pull on my repositories with HTTPS remote URL where 2FA and SSH is enabled on admin/owner. So what is the risk in this approach?

[Pramodh M]

@Bitwise DEVS 

Yes giving them Write Access will surely give them read but not more than what Write access can do, they will not be able to see the settings tab which requires admin access

If you give them your App Password, they will also have access to your entire account with that scope, and I guess that's not what you want.

You need those users to access only the repo right? So invite them over to repo and let them authenticate to the create by their convenient method

[Bitwise DEVS]

Okay so there is no much of a risk on the second approach unless you gave them a wrong scope with a wrong permission right? Anyway I want to clarify again that the only way for them to push and pull when a 2FA and SSH being enable is them giving me their public key or App Password for HTTPS remote URL. Inviting/adding them as a member is not enough, it only gives them access on the repo via Bitbucket Cloud but not when working with IDE nor terminal (local device).

[Pramodh M]

Yes @Bitwise DEVS Correct

[Pramodh M]

@Bitwise DEVS 

Can you please accept the answer if it solved your queries?

[malee]

Seems like solid advice to not share App Password between users, but I cannot spot the proper way to work with pipelines this way.

Example: When triggering another pipeline, it is required to give username and AppPassword. It is referenced as environment variable, but that means I need to a share AppPassword !? - or am I missing something?

https://bitbucket.org/atlassian/trigger-pipeline/src/master/ 

PS: Workaround planned currently is to create a new user that just serves as service account for all pipeline work. That seems to be the most safe solution.

[Theodora Boudale]

Hi @malee,

You can use a secured variable and its value will be hidden in the build logs.

However, even secured variables can be retrieved by all users with write access to a repository (e.g. someone could edit the bitbucket-pipelines.yml file and echo the variable in a file defined as an artifact).

It is common for organizations to use a separate account as a service account for such operations, and we recommend that.
You can give this account access only to specific repos, in order to limit what can be accessed with its app password.
When generating an app password for a pipe, only check the minimum permissions required for the pipe to work.

Kind regards,
Theodora