Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter user48958

    (@user48958)

    Thanks, we did migrate to it.

    But I’m worried that you have a large number of installs and there are other reports of this issue too. So if you don’t plan on investigating and resolving this security vulnerability, a socially responsible thing to do would be to de-list this plugin and educate people on migrating away via an upgrade alert. I say that in good faith – no disrespect.

    Thread Starter user48958

    (@user48958)

    Yes, it was setup by the previous administrator and was enabled for all important users. I can confirm it worked in the past but was entirely broken recently. To be honest, we couldn’t believe it.

    Not sure if it’s incompatible with the latest wordpress or if something broke during this plugin’s standard upgrade path or if it’s something else entirely.

    The fatal issue is silent failures – the failure of an important security feature should always be “in your face” and defaults etc should be biased towards that. Ideally, the plugin should present the 2FA prompt only for accounts that have 2FA enabled. Till that’s fixed in the UI (as a 2 stage login), a quick fix would be to NOT ignore any code that’s submitted (check 6 digits long and if you get a code for an account without 2FA enabled, abort + warn).

    Collaborating with the “Two Factor” plugin authors isn’t a bad idea either; their implementation covers yubikeys and the login UI is done correctly as a 2 stage process.

    My $0.02

    Thread Starter user48958

    (@user48958)

    Also, it’s evident that this comes from define('DB_CHARSET', 'utf8'); in wp-config.php. Not a fan of how mysql handles UTF8 in a brittle manner but since even the latest WP install uses utf8 in the default wp-config.php perhaps there is a better utf8 vs utf8mb4 detection for your script?

Viewing 3 replies - 1 through 3 (of 3 total)