Two-step verification is here

By on September 10, 2015

Two-step verification (also known as two-factor authentication) is now available on Bitbucket. It’s been one of our most requested features and we’re excited to ship it.

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.

Screenshot 2015-09-09 15.18.18

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.

48 Comments

  • Ben Strawson
    Posted September 10, 2015 at 3:01 pm | Permalink

    Is there any way for team administrators to enforce this or at least determine whether members have this enabled?

    • Eric Wittman
      Posted September 10, 2015 at 5:27 pm | Permalink

      Hi Ben. With the current implementation this is not supported however it’s a great suggestion and something we’ll consider for future iterations.

      • Anders Norremo
        Posted March 8, 2016 at 3:17 pm | Permalink

        Eric – Any updates on this? I was reading about the Buffer breach and it was repository related. Their suggestion is to add two factor auth to all users for the repos.

      • Laurent Bel
        Posted May 25, 2016 at 9:40 am | Permalink

        Hi @Eric@disqus_YFbQYbW9tl:disqus , any news on this ? This is something we clearly would like to have, ideally at both repo and team level. Thanks.

  • FBM Static
    Posted September 10, 2015 at 5:33 pm | Permalink

    After 3 years, you’d think everyone’s already moved to github.

    https://bitbucket.org/site/master/issues/5811/support-two-factor-authentication-bb-7016

    • Posted September 15, 2015 at 4:12 am | Permalink

      You’re thinking wrongly

    • Posted September 22, 2015 at 8:59 am | Permalink

      Yes, it’s been a long time, but since GitHub’s pricing is out of our league for private repos it was rejected as an option.

      • Posted March 21, 2016 at 6:56 am | Permalink

        I’d say that’s most users’ reason for staying.

        Realistically it’s out of our league too, but with enough convincing the boss, I managed to get us on GitHub’s Silver tier here.

        Maybe if BitBucket add FIDO U2F support we’ll reconsider our options.

  • Shad
    Posted September 10, 2015 at 6:21 pm | Permalink

    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?

    • mbertrand80
      Posted September 11, 2015 at 1:28 pm | Permalink

      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.

      • jonnymaceachern
        Posted November 6, 2015 at 6:30 am | Permalink

        I’m currently watching the app-specific password issue, but is there any way to track when 2 factor auth will be available in SourceTree?

  • OrangeTux
    Posted September 12, 2015 at 2:27 am | Permalink

    API still uses single step authentication, providing fake security. As an attacker I would try API to get access.

    • Erik van Zijst
      Posted September 12, 2015 at 10:17 am | Permalink

      Not sure what you mean? When 2fa is enabled, Basic Auth on the API no longer works.

      Can you elaborate on what you mean?

      • mstrap
        Posted September 14, 2015 at 3:33 pm | Permalink

        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.

        • Erik van Zijst
          Posted September 14, 2015 at 11:56 pm | Permalink

          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.

          • mstrap
            Posted September 15, 2015 at 12:24 am | Permalink

            “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.

          • mbertrand80
            Posted September 15, 2015 at 9:03 am | Permalink

            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.

          • Erik van Zijst
            Posted September 15, 2015 at 10:54 am | Permalink

            On desktop apps you don’t need to ask for the user’s password.

            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.

            For more info: https://confluence.atlassian.com/display/BITBUCKET/OAuth+on+Bitbucket#OAuthonBitbucket-Authorizationcodegrant

          • mstrap
            Posted September 15, 2015 at 2:47 pm | Permalink

            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?

          • Erik van Zijst
            Posted September 15, 2015 at 3:51 pm | Permalink

            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.

            FWIW, this is what we’re going to do with SourceTree also.

  • Posted September 15, 2015 at 4:13 am | Permalink

    I’m really happy for this ?????!!

  • Posted September 15, 2015 at 7:08 pm | Permalink

    Is there plan for app-specific passwords implementation? Cause when we talk 2fa vitrifaction, we usually want to see app-specific passwords either.

  • Posted September 23, 2015 at 7:55 pm | Permalink

    Does this mean 2FA is on its way for the Atlasssian cloud/ondemand products, e.g. JIRA, Confluence?

    • Mark Adams
      Posted September 24, 2015 at 11:41 am | Permalink

      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!

      • Posted October 26, 2015 at 6:09 am | Permalink

        .. and pls don’t forget to implement the emerging FIDO U2F standard (hint: Github added u2f support recently)

        • Alastair Wilkes
          Posted June 14, 2016 at 7:11 am | Permalink

          FIDO U2F is now available! You can add your key in on the two-step verification settings page.

  • solatic
    Posted September 25, 2015 at 12:25 am | Permalink

    Hi, what about Yubikey/FIDO U2F support? TOTP is less secure.

    • Posted October 26, 2015 at 6:08 am | Permalink

      @mbertrand80:disqus – It would be great to hear if and when the emerging U2F standard is being implemented, as we plan to issue Fido U2F keys to all our employees. Hint: Github has it… 🙂

    • Alastair Wilkes
      Posted June 14, 2016 at 7:07 am | Permalink

      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

      • Posted June 14, 2016 at 7:51 am | Permalink

        Wow, very cool – just configured, works like a charm. Of course, now it would be very cool if I could force our team to use 2FA 😉

  • Zekian
    Posted September 25, 2015 at 12:25 pm | Permalink

    How about FIDO U2F?

  • Michael Scarchilli
    Posted October 5, 2015 at 4:27 pm | Permalink

    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.

  • Ajay Gupta
    Posted October 7, 2015 at 4:07 am | Permalink

    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?

    • mbertrand80
      Posted October 7, 2015 at 10:09 am | Permalink

      We’re working on App Passwords/Personal access tokens that will enable https access. I don’t have a timeline for the release, but it is coming.

  • Dominic Cerisano
    Posted October 7, 2015 at 3:23 pm | Permalink

    Before diving into Bitbucket TOTP, I would like to know if anyone has successfully done it with Eclipse eGit. The https/oAuth integration works flawlessly, so I am ready to take the plunge.

    • Dominic Cerisano
      Posted October 12, 2015 at 10:46 am | Permalink

      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?

  • maaraneasi
    Posted October 27, 2015 at 11:05 am | Permalink

    Please add FIDO U2F!

    • Alastair Wilkes
      Posted June 14, 2016 at 7:11 am | Permalink

      FIDO U2F is now available. You can add your key in on the two-step verification settings page.

  • nikmolnar
    Posted December 2, 2015 at 4:08 pm | Permalink

    It would be great to have an SMS backup. Since the code generator is tied to a specific device, a fire that gets your phone and backup codes would mean your account is forever inaccessible.

  • davemagic
    Posted February 2, 2016 at 9:22 am | Permalink

    does not seem to work on mac, tells me to use SSH, I am using SSH, always have used SSH

  • Posted April 1, 2016 at 8:38 am | Permalink

    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 🙂

  • Abhinandan Kothari
    Posted April 25, 2016 at 8:51 pm | Permalink

    And updates/News on Yubikey/FIDO U2F support ??

  • brent
    Posted July 14, 2016 at 7:44 am | Permalink

    Warning. You may have issues with composer and private packages on bitbucket with multi-part authentication.