Core: Reset compromised passwords after 2FA failures #482
Conversation
|
Do we want to consider the attempt counter to be using a transient to benefit those sites running with memcache etc, rather than it always being the DB? Looking at the suggested alternatives metioned that seems like the approach taken for passwords and considering a large site, and the worst case scenario (everything is compromised), then it does open it to resource saturation. The other thing regarding resetting passwords and emailing the reset link - is this ok? what if the account is compromised via password and the email address is updated? Or am I thinking too far ahead of the scenarios scope? |
That's a good idea 👍🏻
Wouldn't the attacker be prevented from changing the address until they fully authenticate (including 2FA) ? Logging in via the REST API and XML-RPC are disabled by default. |
Yes, I was considering those sites who had disabled the functionality for various reasons, like syncing content for search, or applications unable to handle a 2FA workflow . |
iandunn
force-pushed
the
reset-compromised-pw
branch
from
3beacc5
to
2d5c53b
Compare
|
I switched to a transient in 2d5c53b 👍🏻
🤔 If the attacker was using the REST API or XML-RPC, then that wouldn't trigger the reset. They could still trigger it if tried to login via the browser. If they did update the address, then you're right that this wouldn't be effective. It seems like that's the risk the owner takes when enabling REST/XML, though; the entire plugin is essentially disabled at that point, so I'm not sure the user is any worse off. The user would still get a notification from Core (at their actual address) letting them know that it was changed, though. Am I missing something, though, or is there something you'd suggest instead? |
Probably not 😄 I was just working through some scenarios where this is an edge case (Jetpack content sync) but it seems like the approach is to allow only these specifically, so it depends whether the plugin should handle this (probably not) or it's handled on a per-site basis. |
|
@dd32 raised some good points that would improve this PR. There's also overlap with #510 that could be incorporated:
If a hybrid approach is desirable, though, then this PR could also be refactored to build on top of failure tracking in #510, rather than implementing a separate mechanism. |
After a reasonable number of 2nd-factor attempts, it's safe to assume that the password been compromised and an attacker is trying to brute force the 2nd factor. The existing rate limit mitigates brute force attempts, but many 2nd factors -- like TOTP and backup codes -- are very weak on their own, so it's not safe to give attackers unlimited attempts. Since we know that the password is compromised, we have the responsibility to reset it and inform the user. That will guarantee that attackers can't brute force it (unless they compromise the new password).
iandunn
force-pushed
the
reset-compromised-pw
branch
from
b44e7f6
to
45f2040
Compare
With this change, I'm supportive of this PR approach of resetting passwords, as it's far far less likely to incorrectly affect end-users. |
Fixes #477
Builds on top of #510
After a reasonable number of 2nd-factor attempts, it's safe to assume that the password been compromised and an attacker is trying to brute force the 2nd factor.
get_user_time_delay()mitigates brute force attempts, but many 2nd factors -- like TOTP and backup codes -- are very weak on their own, so it's not safe to give attackers unlimited attempts.Since we know that the password is compromised, we have the responsibility to reset it and inform the user. That will guarantee that attackers can't brute force it (unless they compromise the new password).