CUNY Academic Commons

If we proceed with this—and we should talk through whether this may be a solution to a problem that we don't have but are anticipating—perhaps the solution could allow one-time 2FA per device (or is time limited in some generous way). I access the Commons on a number of devices, and the login is often glitchy using my password manager (I haven't gotten around to opening a ticket on that yet, but will). Want to take extra care not to introduce any pain.

Also, heads up that CUNY CIS is moving towards 2FA for all CUNY-hosted services. Might make sense to align with their practices, once they're defined, to minimize confusion. Can you keep you posted on that conversation but you might also check with Lihua.

Thanks for the comments, Luke.

this may be a solution to a problem that we don't have but are anticipating

We've fielded two separate instances in the last three days of user accounts being compromised, very likely because of shared passwords breached on other sites. That's what's driving this conversation.

Also, heads up that CUNY CIS is moving towards 2FA for all CUNY-hosted services. Might make sense to align with their practices, once they're defined, to minimize confusion. Can you keep you posted on that conversation but you might also check with Lihua.

We're in conversation at a high level, but this is great to know. It's definitely worth investigating whether coordination is possible (and wise).

If we are looking at single-sign on with CUNY and if their SSO will support 2FA, we should look at implementation in #4635 instead.

Otherwise, if we want to add 2FA at the WordPress level, the mentioned 2FA plugin looks good at a glance. We should do a custom BuddyPress integration on a user's "Settings" page. I think 2FA can be set up after initial registration. We shouldn't complicate the registration process with a 2FA step IMO.

SSO with a central CUNY system is a long way off, and may never happen. So I don't think we should hold off more immediate improvements in expectation of consolidating authentication.

Agreed with your point about registration. Let's see if other team members want to chime in before we begin implementing anything.

From a few conversations in calls and emails, I think we should table work on this until we can all discuss as a wider group, hopefully during our first meeting of the new semester in a couple of weeks (schedule info to come soon). Perhaps we can still come up with a plan forward to work on for the fall.

To follow up on Friday's group meeting, we decided to move ahead with this implementation of the Two Factor plugin. It would be nice though as Ray suggests to make the text and a few of the more technical elements as user-friendly as possible. Ray, do you want to keep us posted in the ticket here what you're able to adjust via pull requests to the plugin team, and then we can figure out what else we want to add on our end?

Thanks for testing, Jeremy!

Can I ask you to try the following suggestion? https://github.com/WordPress/two-factor/issues/211#issuecomment-460654063

PS: Try hold for about 3 seconds, not just tap.

If that works, I'll adjust the message to add this tidbit. Can you also test on a Chromium browser to see if the problem might be Firefox-related?

Also, thanks for the screenshot of the Security Keys table. I was able to fix up some of the styling to better match the 2FA page in the admin area.

No luck - I tried holding for >3 seconds in both Firefox and Chrome and there's no indication it's seeing anything.

I poked at the source of the page a bit and it seems like a couple things are missing:

• The `fido-u2f-api` and `fido-u2f-login` scripts enqueued by the plugin. https://github.com/WordPress/two-factor/blob/736473edf5ff6d2fed18ba2406c772f30950343c/providers/class-two-factor-fido-u2f.php#L128
• The localized `u2fL10n` variable that `fido-u2f-login` expects. https://github.com/WordPress/two-factor/blob/736473edf5ff6d2fed18ba2406c772f30950343c/providers/class-two-factor-fido-u2f.php#L179

The message about the key and `u2f_response` hidden input field is there as expected as part of the overall 2FA validation form the plugin provides: https://github.com/WordPress/two-factor/blob/736473edf5ff6d2fed18ba2406c772f30950343c/class-two-factor-core.php#L608-L620

Nothing about the plugin code makes it seem like those scripts are enqueued in any unusual way, so I'm not sure what would be stopping them.

Thanks for the debugging, Jeremy!

This gave me a clue. We use a customized login template, which uses the current theme's template. This setup involves removing all footer scripts from being enqueued, except for ones we manually enqueue ourselves:
https://github.com/cuny-academic-commons/cac/blob/07a1e37b850dc0147c7815c2a9b250e3f0ab6f1e/wp-content/mu-plugins/cac-login-template.php#L385-L388

This is done to stop unnecessary external assets that other plugins might add to the footer from being loaded. If you're interested about the code, check out #12108 for more info.

Anyway, I've just manually enqueued the fido-u2f-login script when we're on the U2F login page on cdev. Can you give it another try? Let me know if it works or not.

I think we're close. Your answer sounds correct, but I'm not sure it's working yet. :)

Still no luck with the key, but I don't see the fido-u2f-api or fido-u2f-login scripts enqueued yet. I'm not sure if something else funky happens when everything is unenqueued?

I think we're close. Your answer sounds correct, but I'm not sure it's working yet. :)

Found the bug. The two-factor plugin doesn't tell you which 2FA provider is currently running on the login page, so I tried to code a workaround by declaring a global flag during one of the strings that appears on the login page. The bug was I hooked into the wrong filter! The U2F script should now be properly enqueued.

Jeremy, can you try to login with your security key again on the development site when you have a moment? Thanks!

Hey, there we go! Works great in both Chrome and Firefox.

Just passing on a bit of testing feedback from Anthony Wheeler: "The Recovery Codes take a few seconds to populate. I don’t really know if there’s anything that can be done about that, but my instinct was to start clicking other things around the page (like the Enable/Primary checkboxes, which were unresponsive while waiting for the codes) to make sure it was working."

Ray, maybe you're familiar with this? I tested myself and it did take a second or two to see the codes. Maybe there's a way to add some sort of loading wheel or interstitial?

I tested myself and it did take a second or two to see the codes. Maybe there's a way to add some sort of loading wheel or interstitial?

Done. I've added a spinner to the "Generate New Recovery Codes" button when it is clicked:

A couple more things from testing - can we make it a bit more clear that this is all optional? Maybe just by making the top header "Two-Factor Authentication (Optional)"?

I think adding the word "Optional" implies that 2FA isn't needed. While that is technically true, I'd prefer that we do not use the word so prominently for the heading.

Perhaps we can modify the description below the heading to:

Two-factor authentication adds an optional, additional layer of security to your account by requiring more than your password to log in.

If we think that using "(Optional)" in the header is better, then I'll make the change though.

If I select something as Primary, should it automatically check the Enabled box?

Yes, it should. I didn't sufficiently test the "Primary" column. I was mostly testing with clicking on the 2FA name itself. This should now be fixed on cdev.

Also, we're noticing some odd behavior/interplay between the Enabled and Primary check and radio buttons. See the attached screencast.

Thanks for the screencast, Colin. Most of this should be solved with the fix to select the Enabled box when clicking on a Primary option.

About the Recovery Codes option, I tried to make an exemption so it will not automatically be selected as Primary because this option really shouldn't be a selectable, primary option (see https://github.com/WordPress/two-factor/issues/292). With that being said, most of the wonkiness should be gone now. Latest changes are up on cdev. Let me know if anyone else encounters any problems with the selection.

I've also added a documentation draft on the Help site: https://help.commons.gc.cuny.edu/?page_id=9429&preview=true. Feel free to make any changes.

Once the article is live, the page should be added to the personalize-menu so it shows up in the sidebar.

Thanks for this, Ray. The spinner on recovery codes looks good to me in cdev, and I'm fine with changing the description line to include "optional" as you did rather than the heading. Good point there on the prominence.

On checkbox/radiobox selection stuff, it's working fine for me now to select a new option as Primary and then see the Enabled box also checked automatically. But when I just check Enabled for a new option, it's also selecting that as primary automatically. So if for example I have Email as Enabled and Primary but then check Security Keys as Enabled, it makes it also Primary when maybe I still want Email to be Primary. Does that make sense, or should I screencast again?

Thanks too on the documentation, I'll let you know if we need anything else there.

So if for example I have Email as Enabled and Primary but then check Security Keys as Enabled, it makes it also Primary when maybe I still want Email to be Primary.

Good catch, Colin. This should be fixed on cdev. Enabling another provider should no longer check the new provider as Primary if there is already a Primary provider selected.

Thanks Ray, this is all looking/working great now!