Log 2FA activities

[iandunn]

It'd be good to log Stream or MC events when:

• A 2FA provider is enabled/disabled - including the user who changed it (b/c it could be a super admin)
• A backup code is used
• The recovery process is used (details TBD)
• Anything else?

That way we have an audit trail to help if an account is compromised, and have stats around how often recovery is needed, etc.

Related WordPress/two-factor#462, WordPress/two-factor#476

It may be best to add something like do_action( 'two_factor_log', $event ) upstream, and that could be used for those issues above and for this issue. Having a centralized action would let this plugin automatically log new events that are added upstream, but we still conditionally ignore them if we wanted to.

[pkevan]

Anything else?

Depending on if we allow it or not:

• when backup codes are regenerated
• when a user runs out of unused backup codes since they are prompted to regenerate via an admin notice

I also wonder if we want to log the password reset due to 2FA failure, as per: WordPress/two-factor#482

[iandunn]

Yeah, those are good ideas 👍🏻

[dd32]

I think this would make sense to Contribute upstream to Stream, so I've opened xwp/stream#1386

[pkevan]

A lot of the potential logging hooks would move with the introduction of WordPress/two-factor#504, so probably worth waiting until that is merged before attempting to add in any new hooks.

[iandunn]

@pkevan 504 has merged now 👍🏻

[tellyworth]

Decision needed: is this a blocker for launching the MVP, or should we punt it to the next iteration?

[iandunn]

I think we can punt to clearly indicate that it's not a blocker for the MVP. If it merges before we launch, though, then we can definitely include it.

[dd32]

I've started some some logging via WordPress/wporg-mu-plugins#643

Included (as of right now)

• Backup codes regenerated
• Provider enabled/disabled
• Authenticated via 2FA (and which method)
• TOTP setup
• Security Key registrations & deletions.

Things not covered (yet?)

• A backup code is used (Technically, I guess that's inferred by the auth'd by backup method?)
• when a user runs out of unused backup codes (I don't think this is worth logging on?)
• the password reset due to 2FA failure (There's ZERO actions to catch this on AFAICT)

[pkevan]

• A backup code is used (Technically, I guess that's inferred by the auth'd by backup method?)
• when a user runs out of unused backup codes (I don't think this is worth logging on?)

Not sure if it works like this, but the logging question got me thinking about how we tell the user about the status of their backup codes. Should there be a prompt once you get below a certain threshold, or run out to direct the user to regenerate them before locking themselves out?

Be interesting to see how often backup codes are used generally, maybe with an MC stat or similar.

[dd32]

how we tell the user about the status of their backup codes

I was thinking that the interstitial added via WordPress/wordpress.org#351 could be extended to:

• Prompt after a month that they have their Recovery codes
• Prompt to verify the methods listed are still current (Ie. do you still have that security key after not using it for 3 months? - That Passkey might be on an old laptop for example)
• Prompt after login when they have less than 5 backup codes remaining
• Prompt regularly to verify their email address is current?

Be interesting to see how often backup codes are used generally, maybe with an MC stat or similar.

I agree, a MC stat of auths per day by type would be potentially useful.

[pkevan]

I was thinking that the interstitial added via WordPress/wordpress.org#351 could be extended to:

• Prompt after a month that they have their Recovery codes
• Prompt to verify the methods listed are still current (Ie. do you still have that security key after not using it for 3 months? - > That Passkey might be on an old laptop for example)
• Prompt after login when they have less than 5 backup codes remaining
• Prompt regularly to verify their email address is current?

Part of the problem with potentially over-prompting is that they become irrelevant, and also, if we're doing something different to other services, the users will probably be annoyed by them!

Just thinking how many times i've been prompted to either check my settings or what methods are valid - it's probably close to zero times, unless being forced to change the method of auth.

[dd32]

Part of the problem with potentially over-prompting is that they become irrelevant, and also, if we're doing something different to other services, the users will probably be annoyed by them!

Yep, totally agree with you!

Apparently GitHub does a 1-month after 2FA enable to verify the settings are expected, which is probably enough to prompt/remind you that "oh.. I think i threw that scrap of paper out.." or "I was going to add that extra key later and never did.."

WordPress Core does annual "Is your email up to date?" notices too, which is super rare enough. Perhaps that kind of thing would be worth doing additionally if it was 6mth+ since last login or so.

[pkevan]

WordPress Core does annual "Is your email up to date?" notices too, which is super rare enough.

Never got one of these afaik

[dd32]

WordPress Core does annual "Is your email up to date?" notices too, which is super rare enough.

Never got one of these afaik

It's disabled on WordPress.org, and is specifically for the main WordPress site admin email, not the account emails.
https://github.com/WordPress/wordpress-develop/blob/dfd1de09afbb5b3c4c7a959b20a1f5fa7011aa46/src/wp-login.php#L580-L758
https://core.trac.wordpress.org/ticket/46349

Turns out that's every 6 months.