#34409 closed defect (bug) (fixed)
random_bytes() prevents me to log in if PHP is 5.3.5
Reported by: | imath | Owned by: | dd32 |
---|---|---|---|
Milestone: | 4.4 | Priority: | high |
Severity: | blocker | Version: | |
Component: | General | Keywords: | has-patch |
Focuses: | Cc: |
Description
Since r35365, when i try to log in WordPress on a local WAMP stack using PHP 5.3.5 i get this fatal error :
Fatal error: Maximum execution time of 60 seconds exceeded in D:\path_to_wp\wp-includes\random_compat\random_bytes_openssl.php on line 64
xdebug is giving me these pieces of information :
Call Stack # Time Memory Function Location 1 0.0072 689848 {main}( ) ..\wp-login.php:0 2 0.3460 25607752 wp_signon( ) ..\wp-login.php:776 3 0.3611 25695560 wp_set_auth_cookie( ) ..\user-functions.php:94 4 0.3611 25696040 WP_Session_Tokens->create( ) ..\pluggable.php:921 5 0.3611 25696648 wp_generate_password( ) ..\session.php:147 6 59.2952 25697008 wp_rand( ) ..\pluggable.php:2138 7 59.2952 25697168 random_int( ) ..\pluggable.php:2185 8 59.2953 25697392 random_bytes( ) ..\random_int.php:148
When i switch to PHP 5.4.9 i have no problem ??
As WordPress PHP required version is 5.2.4, i thought i should add this ticket. Maybe it's relative to my WAMP Stack, but just in case...
Attachments (1)
Change History (16)
#1
@
9 years ago
- Component changed from Login and Registration to General
- Milestone changed from Awaiting Review to 4.4
- Priority changed from normal to high
- Severity changed from normal to blocker
#2
@
9 years ago
Noting it here, although it doesn't apply specifically to this case, in PHP 5.3.4 and earlier on Windows it's a known issue that openssl_random_pseudo_bytes()
may block for a significant amount of time.
On later versions it's also known for being slow when running under CGI.
#3
@
9 years ago
Hi @dd32
Thanks a lot for your quick reply. It's probably this WAMP stack configuration that is getting old i guess :)
Openssl is 0.9.8o
And here's a truncated phpinfo if it can help https://cldup.com/KPPgwfVME2.html
But i'm not sure it's linked to the Openssl version as when i switch to php 5.4.9 it's the same.
#4
@
9 years ago
Looks like although this function exists in the OpenSSL extension, on windows systems it doesn't use the OpenSSL provided function and instead prefers the Windows Crypto API instead, however that's only in PHP 5.4.1+.
#5
@
9 years ago
If I'm reading this correctly, we should probably prevent openssl_random_pseudo_bytes()
from being invoked on PHP < 5.3.3; does that sound right to you @dd32?
#6
@
9 years ago
https://github.com/paragonie/random_compat/releases/tag/1.0.10 - This should fix the known problem that Dion referred to on Windows.
If you change [this constant](https://github.com/paragonie/random_compat/blob/2fa50aa2f17066fa74ba00d943e8cee1a98284af/lib/random.php#L114) from 50304 to 50401 does this performance problem evaporate?
(Note that OpenSSL is our last resort, so this means that you're not benefiting from a CSPRNG on outdated versions of PHP on Windows.)
#7
@
9 years ago
@sarciszewski
Well the file is a bit different in WP Core > https://core.trac.wordpress.org/browser/trunk/src/wp-includes/random_compat/random.php
But if i apply the attached patch (34409.patch) using the 50401 constant it's now possible to log in using PHP 5.3.5.
#8
@
9 years ago
Okay, I opened a ticket on random_compat to discuss our way forward: https://github.com/paragonie/random_compat/issues/73
#11
@
9 years ago
So far all i've been able to determine is that yes, random_int()
can be slow with OpenSSL on windows under certain situations in <= php 5.3.8. Using XAMPP has shown that every call to random_int()
takes roughly 1.2s using OpenSSL in those versions of PHP, which is about the same speed as PHP 5.3.0~5.3.3 in my testing.
PHP 5.4.7 is orders of magnitude faster (The XAMPP version which includes 5.4.4 is broken, and none include 5.4.0/5.4.1).
I'm going to bump the WP version to PHP 5.4.1+ for OpenSSL since that's when the last major change occurred, and we can't really risk it.
#12
@
9 years ago
The builds directly from http://windows.php.net/ don't suffer the same problem when running as CLI scripts, so i suspect it's something to do with how they're used when run as mod_php.
Hi @imath,
Thanks for reporting this! It's definitely not the intended behaviour.
Can you provide some more details about your server environment? Specifically the version of OpenSSL which you're running?
cc @sarciszewski