Security audit

[iandunn]

We should get some extra eyes to review everything for vulns before the launch

[pkevan]

Had a chat with xknown today regarding the roll-out, he's going to take a look at the current code and implementation.

Some things mentioned were:

• ideally we add a customization to support encrypted secrets
• adding rate limiting to the 2fa verification code (we've talked about this in Core: Reset compromised passwords after 2FA failures two-factor#482)
• invalidating verified totp codes so they can't be reused (this would apply if we were using email or SMS codes, which we aren't currently planning), it's done on wp.com by storing successfully used codes.

There were some additional reading in https://medium.com/@ISecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35 and https://sirtp2.wordpress.com/2017/03/27/2fa-bypasses-for-the-price-of-one/ which we should take a look at.

Combing through some of the commits on the wp.com authentication script is also worth looking through (maybe we already have) from mu-plugins/two-step-authentication

[iandunn]

he's going to take a look at the current code and implementation.

It might be worth waiting until we're done with the code, since some things will change between now and launch

adding rate limiting to the 2fa verification code (we've talked about this in WordPress/two-factor#482)

👍🏻 I moved that back into #1

[iandunn]

Reading through those articles, it seems like these are the relevant things that we should test:

11. Improper Access Control in the backup codes request. Backup codes are being generated immediately after 2FA is enabled and are available on a single request. After each subsequent call to the request, the codes can be regenerated or remain unchanged (static codes). If there are CORS misconfigurations/XSS vulnerabilities and other bugs that allow you to “pull” backup codes from the response’ request of the backup code endpoint, then the attacker could steal the codes and bypass 2FA if the username and password are known.

7.1) 2FA ignoring when recovering a password. Many services perform automatic login into your account after completing the password recovery procedure. Since access to your account is provided instantly, when you log in to your account, 2FA can be skipped and completely ignored. If an attacker gains access to the victim’s email (he can hack the account using phishing, brute-force attacks, credentials stuffing, etc.), he can bypass 2FA, although in this case 2FA should protect the account. At the moment, for 2FA there is a check of the Google Authenticator code or the backup code, but not the code from the email, so this Bypass makes sense.

3. 2FA bypass by substituting part of the request from the session of another account. If a parameter with a specific value is sent to verify the code in the request, try sending the value from the request of another account. For example, when sending an OTP code, the form ID/user ID or cookie is checked, which is associated with sending the code. If we apply the data from the parameters of the account on which you want to bypass code verification (Account 1) to a session of a completely different account (Account 2), receive the code and enter it on the second account, then we can bypass the protection on the first account. After reloading the page, 2FA should disappear.

7.1 would also apply when resetting the password. Any needed work there should probably be done in the upstream plugin. Related WordPress/two-factor#484

All of those should be tested against w.org sandboxes, since local envs won't accurately reflect production's complexity.

[iandunn]

I tested out the above bypasses, and couldn't get any to work. Recovery mode is a potential problem for the upstream plugin, but w.org already has it disabled.

[iandunn]

All of the issues here are either fixed, have open PRs that are tracked in #1 , or are planned for the next milestone, so I'm going to go ahead and close it as complete.