Repository navigation
Fail closed when CSPRNG is unavailable during nonce generation - #877
Conversation
Replace the weak nonce fallback in create_login_nonce() with a hard failure. The fallback used wp_hash() with predictable inputs (user_id, wp_rand, microtime) and was defensive code from the PHP 5.x era. On PHP 7+ (the plugin minimum is 7.2), random_bytes() uses OS-level CSPRNG sources that do not fail under normal conditions. If the CSPRNG is broken, generating a weak nonce is worse than refusing to proceed. Both callers already handle the false return with wp_die(). Closes WordPress#860 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
This PR hardens Two_Factor_Core::create_login_nonce() by removing the weak entropy fallback used when random_bytes() fails and instead returning false, ensuring nonce generation fails closed when a CSPRNG is unavailable.
Changes:
- Replace the
wp_hash( $user_id . wp_rand() . microtime(), 'nonce' )fallback withreturn falsewhenrandom_bytes()throws. - Preserve existing caller behavior: both in-file call sites already treat a
falsereturn as fatal viawp_die().
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ae19978 to
7c38675
Compare
|
@dknauss any reason to close it? |
|
Whoops, that was unintentional — it must have gotten swept up in some automated cleanup I was doing across several repos. Restoring/reopening. |
Intègre les 175 commits accumulés depuis c8c8823 (20/09), dont la release stable 0.17.0 publiée le 28/09 — la première depuis la 0.16.0 du 27/03. Correctif de sécurité déterminant pour ce fork : WordPress#989 empêche un mot de passe classique de contourner la 2FA sur REST et XML-RPC. Notre code testait `did_action( 'application_password_did_authenticate' )`, vrai dès que n'importe quel utilisateur s'était authentifié par application password pendant la requête ; upstream scope désormais la vérification par ID (`$app_password_auth_user_ids`). Les autres correctifs de sécurité de la release (WordPress#877, WordPress#973, WordPress#980) étaient déjà présents ici. Trois PR qui composaient le fork sont maintenant mergées upstream : WordPress#927 (fail-safe), WordPress#917 (rate-limit) et WordPress#882. Notre implémentation locale de WordPress#927 et celle d'upstream sont identiques, d'où l'absence de conflit sur class-two-factor-core.php. Le fork ne repose plus que sur WordPress#845 (enforcement par rôle, approuvée le 24/09 mais non mergée) et WordPress#958. Résolution des trois conflits, upstream retenu dans les trois cas : - tests/class-two-factor-core.php : nos noms de tests contredisaient leurs propres assertions (« invalidates » pour un token vérifié « preserved ») ; upstream les renomme et ajoute test_clear_login_rate_limit. - tests/providers/class-two-factor-email.php : ajout de trois tests de lockout côté upstream, aucun test perdu ici. - readme.txt : notre seul apport propre, la documentation du filtre two_factor_fallback_provider_for_user, est déjà dans leur version. Validation (wp-env, WordPress 7.1 / PHP 7.4) : PHPUnit 308 tests et 932 assertions OK sur les suites single et multisite, dont 10/10 pour le groupe enforcement ; PHPCS 29/29 ; PHPStan 0 erreur ; build OK. Le merge apporte une suite multisite et le support WP-CLI, d'où le passage de 218 à 308 tests et la nouvelle dépendance php-stubs/wp-cli-stubs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Summary
This PR replaces the weak fallback in
create_login_nonce()with a hard failure.The existing fallback uses
wp_hash()with inputs including$user_id,wp_rand(), andmicrotime(). That defensive path dates back to the PHP 5.x /random_compatera. On the plugin’s current minimum PHP version (7.2+),random_bytes()should use the OS CSPRNG and should not fail under normal conditions.If secure randomness is unavailable, failing closed is safer than generating a weaker nonce. Both existing call sites already handle a
falsereturn withwp_die().Change
try { $login_nonce['key'] = bin2hex( random_bytes( 32 ) ); } catch ( Exception $ex ) { - $login_nonce['key'] = wp_hash( $user_id . wp_rand() . microtime(), 'nonce' ); + return false; }