Two-step verification secures your account by requiring a second component, in addition to your password, to access your account. That second step means your account stays secure even if your password is compromised. Bitbucket’s two-step verification implementation is built on the Time-based One-time Password Algorithm (TOTP), to ensure compatibility with mobile apps like Authy or Google Authenticator.

You will find the two-step verification (optional for you to use) in your Bitbucket account settings, which will take you through the onboarding process. More information can be found here.

So I’ve just put a public SSH key onto my bitbucket account, and updated the links to my repos in sourcetree from https to ssh. But when I try to log into bitbucket via sourcetree to see my remote repos it gives me this error message:https://i.gyazo.com/423a427a691cbde3af085ef07f579613.png

My password is certainly correct so I assume its the 2fa… can you help me out?

We know about a few of our own applications that will have some issues with two-step for the time being. In addition to updating the products (SourceTree and Bamboo currently) to support two-step, we’re also working on Application specific passwords

As you note, we’re keeping a running list of applications we know have some issues and will continue to keep that up to date in our documentation.

Erik, does the API already provide a way to submit the 2. factor
(something like “X-GitHub-OTP”)? My goal is to authenticate our
application once using 2fa once, requesting an oauth token (not yet sure how that works) and for subsequent authentications only use that token.

Not yet, but we’re working on a secure alternative to username/password credentials that can be used with scripts.

This system will be akin to Google’s “App Passwords”, which are essentially randomly generated, scoped tokens that never expire. You’ll be able to generate as many as you like and they can be used with HTTP Basic Auth.

Until then you can either use an account that has a strong password and 2fa disabled, or else use OAuth 2. The Client Credentials Grant flow can be used to obtain a refresh/bearer token pair. The only hassle is that you’ll have to refresh the bearer token every hour.

“randomly generated, scoped tokens that never expire” sounds what I’m looking for. Still, it would be important that requesting the token will be possible entirely from within the app for 2fa accounts: Our “app” is a desktop Git client which users do trust enough to enter their BitBucket password once and let the client request the app password which will be stored for subsequent access to BitBucket. This is why I was asking for some additional request property which can be set by the client to send the 2. factor. Redirecting to https://bitbucket.org/user//two-step-verification/login/?next=/api/1.0/oauth/request_token won’t work here. I guess SourceTree is facing exactly the same problems.

For SourceTree, we are changing it to do the OAuth flow. This flow is intentionally designed so that the end user is shown all the permissions, on the Bitbucket website, that the application is requesting, and the user is given the option to not allow the application to proceed. Application passwords should be considered a temporary solution until any client app can be changed to use the OAuth flow for authentication. We do not recommend storing passwords in client applications where at all possible.

Instead, create an OAuth Consumer that uses a custom schema (e.g. myapp://…) and in your app register a callback for that protocol with the OS.

In your app you then open a browser and send the user to bitbucket.org/site/oauth2/authorize?client_id={client_id}&response_type=code where they’ll be able to authorize your app access to their account.

After they’ve approved, the browser’s redirect will be delivered to you app through the custom protocol scheme handler and you’ll have the the user’s refresh and bearer tokens that you can then use for all communication with Bitbucket, including cloning, pushing and the API.

This flow has the additional advantage to users that they wil never have to fork over their password.

Thanks, Erik and mbertrand80. This approach will work for us. The only weak point is that we have to keep the client secret in the code/binaries. But I guess the risk of spoofing here is neglectable. What are your thoughts on this? How will SourceTree deal with this problem?

Yes, you’ll be including both the key and secret in your binary. To ensure that doesn’t lead to security issues, we automatically disable the OAuth 2.0 Client Credentials Flow for consumers with custom protocol schemes.

This effectively means that your credentials cannot be used for anything other than issuing access tokens on behalf of other users. The secret is really redundant, but since the Code Grant Flow requires it and we didn’t want to invent a custom flow unnecessarily, we ended up with this.

Yes! We’re working on a single sign-on solution that will allow you to login to all of your Atlassian cloud products with one username and password. One of the big reasons for doing this is so that we can ship security features (like 2FA) more quickly to all of our products. Keep an eye out for it!

FIDO U2F security keys are now supported in Bitbucket. Visit two-step verification settings
to add your key. If you do not already have two-step verification
enabled, you’ll need to enable it before you can use your U2F key with
Bitbucket. If you have any questions or issues, please comment on this issue: https://bitbucket.org/site/master/issues/12246/add-support-for-fido-u2f

Glad to see this finally. 🙂 The only thing I would change is to let it remember the auth for a certain amount of days or location so we don’t need to use it every single time to log in. For instance at work I always log out at the end of the day, and log in first thing in the morning.

I work for a company where SSH from a corporate machine to an external host is discouraged in favor of SSH. So, 2FA is not an option for me given it does not work without first enabling SSH. Can it be made to work with HTTPS or just not technically feasible?

No answer for a while, so I am going to assume that eclipse secure storage + oAuth is equivalent to adding ssh keys. But is not two-step still vunerable to someone hacking into a bitbucket account via oAuth and just turning two-step off?

With 2FA turned on, authentication via SSH is a must. This leads to a problem: one cannot retrieve the whole list of repos online 🙂
Recently Source received a lot of update with great improvement in terms of user interface. However I found this issue since more than 7 months ago, documented as “known issues” but still the status has always been “scheduled”: “SourceTree will use SSH to do most everything with Bitbucket except build a list of repositories.”

Hope that together with improvement in GUI and minor bugs, this problem is solved in the next releases as well 🙂