Allow team admins to require two-step verification be enabled to access a repository (BB-14289)

Issue #11712 resolved
Daniel Bennett
staff created an issue

The owner of a repository should be empowered to require that all members have two-step verification (MFA/2FA) enabled before they can access the source code.

Official response

Comments (46)

  1. Martin Trneny

    Hi Bitbucket team, could you please give us estimate in which quarter it could be in production? 2fa is nice but our security officer requires to enforce us to use it for all users.

  2. Scott Plumlee

    Feels like there might be a larger issue behind this - the ability for a team admin to actually control the accounts on a team. Currently, each user has to sign up on their own versus the team owner being able to create accounts, as in JIRA. I see this issue is closed, but it seems to have the same premise of wanting to be able to administratively create users: https://bitbucket.org/site/master/issues/9771/api-calls-to-create-users. Know if the roadmap is still to have users always sign up on their own, or will part of the 2FA implementation include more team admin capabilities along with just requiring settings like 2FA?

  3. Dusty Kline

    Really critical feature for the long term; hope it makes the cut soon. Maybe in the mean-time we could at least get auditing? Just some kind of indicator that the people on our team have enabled 2FA (or haven't). Even if users have to opt-in to team visibility of that indicator, it would still be a huge step forward for probably a lot less effort than the full-blown enforcement story.

  4. Tauno Talimaa

    We have currently no way to verify if a team member really has enabled 2FA or not. Even if we can't enforce it, at least provide a way to see who has enabled it and who hasn't.

  5. Paul Winterhalder x302

    This is of serious concern to my organization as well. As I've indicated before, it would be workable if we could even just "audit" to see who has / has not enabled 2FA.

    If we can't at least get a better idea roadmap-wise that this is coming home, I'm thinking that my company will have to change our plans, and maybe head elsewhere.

    Paul.

  6. Dusty Kline

    @Zachary Davis, @Daniel Bennett - It's time for somebody on staff with Atlassian to chime in on this. It's a serious deficiency not just compared to other cloud based VCS systems, but compared to SaaS systems as a whole -- the ability to enforce or at least audit strong security for users with access to our companies' IP is frankly non-optional anymore. What are you doing about it?

  7. Craig Deubler

    Hi, please can you prioritize this. As our team grows it's not feasible to enforce this manually and there's nothing stopping anyone from disabling personal 2FA if they feel like it.

  8. Keiran Sweet

    It's really difficult to continue to advocate this platform when it is quietly standing alone with its 2FA and SAML limitations compared to its competition.

    Would really love an update on this issue...

  9. Alastair Wilkes staff

    Hi there! We definitely agree that this is an important feature for teams. It makes total sense.

    Unfortunately, there are some roadblocks we need to clear before this can be a reality, but in the meantime we do plan to add 2FA enabled/disabled events to the audit log for visibility. It's definitely not the same thing, but we should be able to knock that out soon so you can have visibility. I'll post here when we have an update.

    Not-so-ninja edit: Unfortunately, it turns out the same roadblocks exist for adding those events to the audit log. Apologies for the miscommunication. We'll take a closer look at those roadblocks and return with an update in a couple of weeks - thanks for the patience!

  10. Dusty Kline

    Thanks for at least acknowledging and updating the issue; even a "no-update update" is better than nothing. We're all software people and can generally grok that sometimes architectural issues prevent the accomplishment of things that seem like they should be simple from the end-user perspective. Please keep the updates coming, even if it's more "nothing to report" updates every couple months ... it at least helps the users not to feel like Atlassian is completely unconcerned with this topic!

  11. Ivan Cooper

    Atlassian, this is pathetic. There is not even a way to tell whether users in my organization have or have not implemented 2FA. The choices to implement any sort of 2FA policy are apparently (A) walk around to everyone's desk and watch them log in, or (B) switch service providers. Why would you not take this seriously?

  12. Paul Winterhalder x302

    Hi - thought I'd add a few comments:

    1 - I'm pretty appreciative that Atlassian actually responded to this. Even though none of us love the response, at least acknowledging that the request is being heard is a huge step forward - so thanks, and keep it coming!

    2 - I'm not sure that Atlassian realises that just allowing us to audit whether our users have enabled 2FA is a really good stop-gap on the road to full enforcement. I know that this issue specifies that admins should be able to require 2FA to access a repository, but really, if we could just look at the list of users, and visually see which ones have it enabled, I believe that 80% of our security fears would be addressed.

    I've attached a screen shot from a system that does something similar (see below).

    I can fully understand why full enforcement could take a while to implement - especially since I believe Atlassian is working to consolidate it's user identification / authentication mechanisms across all products. That makes sense, and sadly, would result in delays because you don't want to add this ability to the old system, you want to add it to the new.

    That said, I wouldn't think that it would be a huge deal to add a column to the users list with this additional information - maybe I'm missing something - but want to ensure that you understand that if we had a view like this, we'd all (I believe) feel a lot better. [Feel free to "agree" if you agree folks! :) ]

    2016-08-08_14-07-25.png

  13. Alastair Wilkes staff

    Hi all,

    Thanks for the kind words! I'd like to provide a bit more detail on this issue since the main blocker for doing either of these requests is actually a different feature.

    At present, we can’t reveal an individual's 2FA status to the team because there is no way for a user to consent to providing it. This is exacerbated by the fact that currently, if a user is invited to a team, they are added to that team automatically. So if we added this capability as requested, it would be trivial to get a user’s 2FA status, which would not be good.

    So, before we implement anything in this ticket (even a simple listing or audit log), we plan to add the ability for a user to accept or reject an invitation to join a team. That would open up the possibility to list user 2FA status or even require 2FA, and for a user to decline joining a team if they don’t want to comply or if they don’t want to reveal their 2FA status to a team.

    We still need to work out the details of exactly how that would work (and how migration would work), but the accept invites thing is the first thing to do. We’re looking at doing that and will update when we have a better timeline. Stay tuned!

    Alastair

  14. Brian Rozmierski

    @aldango

    I think you're missing the low hanging fruit. If an admin marks a repo as 2FA required, and that setting is auditable (or at least broadcasted if changed), the fact that a user does or doesn't have 2FA enabled need not be communicated to the admins. (It should, but that can be added later.)

    As long as during the access control check a determination is made if 1) the repo is 2FA-only, and 2) the user is not 2FA enabled then to deny access (with an appropriate error to the user) we'll be going a long way to our goal here, which is to secure the repo.

  15. Daniel Tao staff

    We're nearly finished with our initial implementation of this feature, which we plan to be rolling out gradually as a beta as early as next week.

    We will be releasing an account-level setting that allows you to require that users have two-step verification enabled on their accounts in order to access your private repositories. Users who would otherwise have access but don't have two-step verification enabled will be able to see the existence of said repositories (i.e. they won't disappear from list views), but won't be able to access them directly in the UI, via the API, or over Git/Mercurial.

    This setting will also apply to snippets and wikis.

  16. Daniel Tao staff

    Hey everyone, we recently did a quiet launch of an initial version of this functionality as a Premium feature (premium plans are currently in a free trial until early 2017 when it will be $5/user/month). When you go to your account settings you'll see a new section called "Access controls" where you can enable the checkbox to prevent users from accessing your private content unless they have two-step verification configured on their accounts.

    I need to stress that this is currently a beta release. We are still working on this functionality, so some things might be missing or not work exactly how you'd expect. On that note, by all means please share any feedback you have with us, good or bad.

    I should also note that while our intention is to eventually make an exception for this access control on public issues and wikis (i.e. you should not need to have two-step verification enabled to access any content whose owner has explicitly chosen to make public, even on private repos), at this point in time there is no such exception. If you require two-step verification on your account, everything under your private repositories will be blocked to users without two-step verification configured. The docs are slightly inaccurate in this regard; I will try to get them updated soon.

    Anyway, give the feature a try and let us know what you think!

  17. Michaël Pailloncy

    I pay for ... All private repositories of my company are hosted on BitBucket. I'm just very disappointed that this feature is not included at least in standard plan (must be premium ...). It's difficult to understand why I need to pay more to enforce 2FA for all teammates since they already have the ability to enable it ...

  18. Daniel Tao staff

    Hey folks, I can certainly sympathize with what you're saying. Unfortunately the question of what Bitbucket costs (and what features you get for that price) is above my pay grade! As @Michaël Pailloncy points out, though, the ability to enable 2FA is not something you'll ever need to pay extra for. The overall theme of the Premium plan is that it will specifically benefit larger professional teams, in particular the administrators of those teams who want greater control over the way their work is done. Meanwhile individual users and smaller teams who have less of a need for these features don't have to pay extra for functionality they don't want and won't use.

    I don't expect everyone to be happy or agree with this line of reasoning, but wanted to provide some insight into the intention behind the Premium plan. As for the actual dollar amounts or the specific selection of features in standard vs. premium, though: unfortunately I don't have a ton of insight there, other than to point out the obvious that running a service with millions of users comes with costs, and some people crunched some numbers.

  19. Mike Gruen

    @Daniel Tao -- Great news! So, this seems like an account wide setting and not per repository. That's great for us because that's how we do things BUT makes it really hard to test in a limited way without creating a new team. Or am I missing something? I'd love to give this a try, but our developers will string me up if they suddenly are unable to do their jobs due to some bug or unintended consequence.

  20. Balázs Németh

    @Daniel Tao I get that everything has costs, but bear in mind that everything has a benefit-cost ratio as well.

    The standard plan costs 2$/user/month and offers a LOT of features.

    Meanwhile the premium plan is 5$/user/month and offers minor benefits for us - and I'm guessing to most of the developers out there.

    For example enforcing 2FA and merge checks are useful features we would probably pay for, but the rest (smart mirroring, 2x pipeline build minutes, 2x LFS) is completely irrelevant for us. We obviously needed some solution for those problems before you introduced them, and given that it works fine, we have no reason to change that.

    I get that some has actual hardware resource need - some more, some less - hence it explains why it costs more, but enforcing 2FA has pretty much none.

    In our case right now due to security limitations some project is required to be on a repository that has got 2FA enforced, and paying for premium here would be more expensive than the whole plan with the other git hosting provider where 2FA can be enforced.

    IMO you should have fine-grained plans, where we can actually pay for what we need.

  21. Log in to comment