opencollective
opencollective copied to clipboard
opencollective
[Project] Enforce 2FA at the Organization level
User story
As an organization owner, I want to force all people who can approve expenses and invoices to use 2FA / TOTP
Best solution for this problem
A setting on the organization that forces admin level users to enable 2FA when they next log in.
MVP
A really MVP way of doing this would be to just show that other users have 2FA enabled on their account, so that admin can nag them to enable and know that they have it enabled before promoting the other user to "admin".
A toggle on a settings page that enables this feature, and then a flow for requiring existing admin, on new log in, to enable 2FA on their account.
Metrics
Better security for users.
Documentation
We should add documentation about this feature in the organization admin documentation, with examples of what the flow will look like for new users.
Triage Template (team only)
This template is for members of the team to triage for prioritisation. For more guidance see https://www.loom.com/share/369ab467fbc64dec848085d38ff57ca0:
P1 high frequency, high impact P2 low frequency, high impact P3 high frequency, low impact P4 low frequency, low impact
Examples of high impact - a problem affects users during an essential process (expenses and payments > onboarding and registration > contributing) with no workaround.
High frequency - >10% of users affected (measured as a proportion of total potential users for this case).
agreed. would really help me sleep at night and avoid cumbersome work of chasing people down to verify this.
Big +1 on this one. It's actually a problem we share for admins of https://opencollective.com/opencollective, who get a lot of additional permissions. We have a setting to enforce 2FA for payouts, but that's not enough. You can do a lot of harm outside of payouts just by being an admin of an account: refund payments, make new financial contributions, remove other admins, etc.
Because it's tedious and error-prone to cover all these features one by one, I would propose the following UX:
- Account admin checks a box like "Require all admins to enable 2FA"
- All admins on the account that don't have 2FA enabled instantly get their account deactivated and receive an email with some instructions to move forward
- If they click the link in the email or try to sign in, they're prompted with an "Enable 2FA" screen, and their profiles get reactivated
On top of that:
- Your account should be deactivated when you disable 2FA while one of the accounts you administrate requires it. There should be a decent warning on the page to let you know about that in advance.
- If you get removed as an admin and none of the accounts you administrate requires 2FA, your account should be re-activated
sounds like I might be able to deny someone service if a policy for one affects all user accounts attached. maybe instead we disable the member's priv's on the accounts that they require 2FA for instead?
- block admin rights on collectives that require 2FA for all users that do not have 2FA enabled
- redirect those who hit a admin-only page (say they've bookmarked a page) to the 2FA page in their settings with some information as to why they're here _Collective XYZ requires 2FA for administrators, follow the steps below to enable 2FA'
- highlight elsewhere that this collective requires 2FA and that you need to enable it to perform some actions (i.e. on the Collective's page)
- provide a highlight alongside the 2FA settings menu icon, with some information on that page 'Some of your collectives require 2FA, follow the steps below...'
how does that sound @betree?
That's indeed a nicer UX to not block everything just because one of the orgs you administrate requires you to enable 2FA. Works for me!
For consistency in project management, would be great to create a project board for the project. See https://github.com/opencollective/opencollective/projects/77 and https://github.com/opencollective/opencollective/projects/78 for example with other projects.
The kickoff for this project is planned for Thursday. We'll also investigate the specs for https://github.com/opencollective/opencollective/issues/5998 as a stretch goal to see if it's feasible to include it alongside this one.
A project board for 2FA has been created on https://github.com/opencollective/opencollective/projects/80.
I think that for logging in 2FA is fine but we should implement 3FA whenever a user wants to do something that’s rare + high risk like make a withdrawal or change their login info or disable 2FA and maybe it should be something like coinbase’s verification where they charge you temporarily to your bank account $1.82 for example and ask you to check your bank account and verify the exact change. That’s just one idea off the top of my head because it’s another FA avenue that’s unlikely for the breacher to have gotten into at the same time as the 2FA. Am I thinking too small or what do you all think?
@flowofficial We haven't discussed this topic yet, but there are some related ones: #1738 #5294. It's however out of scope for this issue, which is about enforcing an existing feature on more profiles. I suggest opening a new issue if you think we're missing something.
Kickoff notes
Project board: https://github.com/opencollective/opencollective/projects/80 Slack channel: https://opencollective.slack.com/archives/C0449NYP3K8
Goals for this sprint
- [ ] https://github.com/opencollective/opencollective/issues/6005
- [ ] https://github.com/opencollective/opencollective/issues/6006
- [ ] https://github.com/opencollective/opencollective/issues/6007
- [ ] Stretch goal: https://github.com/opencollective/opencollective/issues/5998
We should keep #5294 in mind while implementing all this.
Long-term & follow-up
We think that Open Collective should enforce some best practices for host admins, and we could decide to force all fiscal hosts to enable 2FA given the powerful features they can access - similarly to how bank apps don't let you the choice of enabling 2FA or not, it's a requirement. It's a long path to get there where education is key (fiscal host admins are not necessarily tech-savvy), but we should already think about:
- Display warnings in the interface (admin dashboard, expense page, etc) to recommend the use of 2FA
- Overall, communicating about that with host admins everywhere makes sense (e.g. onboarding)
- Making sure our documentation for 2FA is accessible and easily understandable
W3 update
- specced out, make a start this week, starting top to bottom from above
I have caught up with the recording and the documentation. I expect to have everything this project needs within this week. A summary of what I'm doing
- Design the 'Security' page in host settings (Works for other profiles)
- Update the 'Policies' page in host settings (Works for other profiles)
- Alerts: "Be aware that your organization is at risk; consider enabling 2FA."
- Block admin rights screen
- Updating the styleguide we use inside settings (I detect many accessibility issues that we can solve by better use of text, I will post a global update that should impact all settings pages).
cc @Betree @hdiniz
Update the 'Policies' page in host settings (Works for other profiles)
@Memo-Es what do we need to update inside this one? My understanding was that we were going to add the 2FA checkbox under this "Security" menu.
The rest looks good!
@Betree, I understand we are putting in 'Security' some stuff from the 'Policies' page like the minimum admins requirement, and the admin cannot approve their own expense.
Just a note to say that, depending on how https://github.com/opencollective/opencollective/issues/5998 goes, we may implement the MVP with the initially proposed solution of completely blocking the account at the sign-in step.
If we're not ready to protect all important mutations with 2FA, then we should make sure there's no way for admins without 2FA to do anything until they activate it.
Making sure we cover all mutations is a complex task, but blocking only the sign-in step is easy.
I understand we are putting in 'Security' some stuff from the 'Policies' page like the minimum admins requirement, and the admin cannot approve their own expense.
@Memo-Es I will strongly advocate against that. We mentioned it in the past, these two are not security features at the moment as they can easily be bypassed by adding or removing other admins. There's already some confusion around that so we should make sure we do not advertise them as security features. They're just policies.
In the future, when (if?) we make sure these are secure (i.e. by not letting your add/remove admins without others' confirmations) then yes, we'll be able to move them to the security tab.
Docs issue - https://github.com/opencollective/opencollective/issues/6155 Release issue - https://github.com/opencollective/opencollective/issues/6156
You aren't able to click on the check boxes, you have to click on the enter square to make the tick box check
Also, should the rolling payouts be showing in the collective settings? This should only be showing for fiscal hosts?
You aren't able to click on the check boxes, you have to click on the enter square to make the tick box check
@shannondwray Good catch, fix incoming in https://github.com/opencollective/opencollective-frontend/pull/8422.
Also, should the rolling payouts be showing in the collective settings? This should only be showing for fiscal hosts?
@shannondwray We're not changing this part: rolling limit stays as a setting for fiscal hosts only.
I'm closing this since the project is now released for everyone in production. Feedback issue opened in https://github.com/opencollective/opencollective/issues/6193.
The reason I was mentioning the rolling limit bit was because it was showing in the collective settings