#77 closed enhancement (maybelater)
Setup two-factor authentication for privileged WordPress accounts
Reported by: | iandunn | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | Login & Authentication | Keywords: | |
Cc: |
Description
All WordPress accounts on the various community sites should be required to pass multiple auth factors when logging in, if they could potentially cause trouble in the event that they were hacked. The existing measures are great, but 2FA would provide an extra layer of protection, without placing an unreasonable burden on users.
Who?
Definitely Admins and Super Admins, but possibly also Editors. Maybe it shouldn't be mandatory for admins on individual WordCamp.org sites, but it should at least be an option.
The SSO adds a couple complicating factors here, though:
- If there are certain sites where it isn't mandatory, there'd have to be a way to ensure that you couldn't just login to a single-factor site and then browse over to a multi-factor site without passing the additional factor.
- Similarly, it will also need to account for the fact that users have different roles on different sites. So, someone whose a Subscriber on site A and administrator on site B should be required to pass the second factor when logging into site B, even if they're already logged in from site A.
How?
Google Authenticator and Duo Security are the first two that come to mind, but there may be others that would fit well. Both have existing WP plugins that could potentially be leveraged one way or another.
Another option might be to use WordPress.com Connect. That would mean relying on an external service, though, and we'd need a way to enforce that the targeted users have 2FA enabled on their account.
What else?
What other issues are there that need to be addressed?
Change History (62)
#2
@
11 years ago
There's also WordPress.com's Google Auth implementation that we could borrow from. Let me know if you want me to send you a copy of it.
One benefit it has over the Google Auth plugin in the repo is that it only prompts for the auth code if the user has 2FA enabled on their account. That's something we'd have to modify the repo plugin to do before we could use it, otherwise users would be confused about what to do with the extra input field.
#3
@
11 years ago
@iandunn: Sure, email me a copy of that. I've been looking at the plugin in the repo and how we can improve it for generic use all-around, sort of thing.
#4
@
11 years ago
Cool, there's also a thread for updating the repo plugin so that the prompt is on a second page.
This ticket was mentioned in IRC in #wordpress-meta by sams. View the logs.
10 years ago
#6
@
10 years ago
This will be easier to do when we get more of the site running similar versions of software. Right now, we're running like 3 different bbPress versions, a couple different WordPress versions, etc. Suggest leaving this off for now until we unify more things.
#7
@
9 years ago
- Priority changed from normal to high
With the 2FA feature plugin in-progress, we should probably use that.
This ticket was mentioned in Slack in #meta by ocean90. View the logs.
9 years ago
#9
@
9 years ago
- Component changed from General to login.wordpress.org
- Priority changed from high to normal
#10
@
8 years ago
FWIW; This should go ahead even if we can't bring 2FA to SVN access immediately.
Something is better than nothing, and we can iterate on adding either a SVN token or proper 2FA challenges for commits after.
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
7 years ago
#13
@
7 years ago
Remaining questions about implementation that come to my mind:
- Do we support a way for a user to disable 2FA when they've lost their access?
- Automated reset-password email style with a time-delay, or do we require that they email the password-resets supportpress?
- Do we want to support backup codes? How should they work?
- Should a backup code be treated the same as logging in normally with a 2FA device or is it more limited?
- Where do users manage the 2FA process?
- Personally I think this is a good time to introduce
login.wordpress.org/my-account
where we can have this kind of thing (and future account-related stuff). That would allow a futureprofiles.wordpress.org
to be a read-only service which would simplify things a bit.
- Personally I think this is a good time to introduce
- How does WordCamp.org/BuddyPress.org/bbPress.org/SVN fit into this?
- IMHO the other *.org properties should be updated to login through
login.wordpress.org
with a SSO redirect back to the property. - SVN access, other HTTP Basic Auth, Trac XML-RPC, etc. would bypass 2FA requirements initially, with future iterations to find a solution there
- SVN: svn+ssh is the only way to do a 2FA challenge
- Alternatively, application-passwords also fit this purpose.
- IMHO the other *.org properties should be updated to login through
#16
@
7 years ago
SVN: svn+ssh is the only way to do a 2FA challenge
Alternatively, application-passwords also fit this purpose.
What do we use currently to connect the SVN authentication to the WordPress database? I believe that it is something custom?
Edit: nm, found it.
#18
follow-up:
↓ 19
@
7 years ago
Reading through the various options and ways to do 2FA with SVN, it seems to me that a form of application passwords is the only way to go. What with so many tools being scripted and automated methods for people to do svn operations, if we want to avoid breaking anything, then using something like application passwords is the only way to do the job.
I'd go so far as to suggest that we generate these application passwords ourselves and provide the users with a method to regenerate them, but not to actually set them manually. This way we can ensure that the passwords are long enough to be secure. An interface would need to exist to provide the button to regenerate them.
For SVN in particular, we would need to modify the forked *_auth_mysql library currently in use, or we'd need to change the queries that it uses so it can find this new svn-specific password and use that.
For security, the app password should only work with the particular use case (SVN password only works with SVN, you can't log in with it on the website) and the app in question should start only using that app-specific password (you can no longer use your website password for SVN commits). These restrictions would only be in place when 2FA is enabled for that specific account.
#19
in reply to:
↑ 18
@
7 years ago
Replying to Otto42:
Reading through the various options and ways to do 2FA with SVN, it seems to me that a form of application passwords is the only way to go.
Yeah, I've looked through everything, and unless we were to use svn+ssh://
there's no real good way other than Application passwords.
FYI, our initial intention is that 2FA won't apply to SVN and other locations we use Basic auth - that's due to these requiring further development around how we actually authenticate it.
I'd go so far as to suggest that we generate these application passwords ourselves and provide the users with a method to regenerate them, but not to actually set them manually. This way we can ensure that the passwords are long enough to be secure. An interface would need to exist to provide the button to regenerate them.
Application Passwords should never be generated by an end-user. The application-password
plugin in use on w.org presently (make/hosting for the test reporters) generates okay passwords but could be better.
I'd also like to extend it to allow us to specify the 'type' of password (This is only for SVN, This is only for XML-RPC, etc).
For SVN in particular, we would need to modify the forked *_auth_mysql library currently in use, or we'd need to change the queries that it uses so it can find this new svn-specific password and use that.
Correct. I haven't discussed this with Systems yet, however I'm thinking that using a Subrequest module for auth would be best, for example nginx has http://nginx.org/en/docs/http/ngx_http_auth_request_module.html - It'd allow us to move the Authentication for SVN into PHP and just use WordPress function calls. Theres a few Apache module choices there, but those implementation details need to be discussed with Systems directly.
It'll also allow us to store/use the "Last time this password was used" functionality.
#47
@
7 years ago
Some things that aren't yet done, that would need to be complete for a full public release:
- Require a code to disable 2FA
- Better superadmin view when editing users (disable-only)
- Expire email and Slack backup codes
- Add support for Trac and other w.org properties
#50
@
7 years ago
Getting Notice: Undefined index: action in wporg-two-factor/wporg-two-factor.php on line 80
when I reload the page that asks me for the authentication code.
This ticket was mentioned in Slack in #core-committers by iandunn. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
7 years ago
#59
@
7 years ago
- Resolution set to maybelater
- Status changed from new to closed
This needs further work at some point in the future, when it can be properly integrated with Subversion and other services. Closing it as maybelater
until we have the resources to do that.
#61
@
7 years ago
A side note to this: I've been chatting to Authy folks, there's no possibility of the WordPress logo being added to the Authy apps, they're not adding new TOTP logos to the apps anymore.
#62
@
6 years ago
This is a paradox.
I am worried, as the WP CMS is globally considered to be focusing on security, but in reality, it's 2018 and there is still no 2-fa on SVN. It's a joke in terms of security.
It was also possible that APP-PASSWORDS could have been utilized for SVN (instead of regular wp password) years ago, so we could have been more secured, but nothing.
Recently I've found that Duo Security does not have individual user device management capabilities. Meaning that administrator intervention is required for a user to, say, get a new phone and hook up Duo on the new device.
I'll audit the existing Google Authenticator code and see how well it works for this task. The Authenticator system is not centrally managed and thus probably a better fit.