Make sure wp_generate_password() never generates a string containing 0x to prevent blocking from mod_security

[ReneHermi]

A string/password that is generated by wp_generate_password() can lead to a block of requests by security plugins or modules like mod_security() because it's possible that a generated string can contain the string part 0x.

This part triggers the server security module because literals that start with 0x are hexadecimal integers.

Best would be to prevent this character combination in core of this method by doing a simple replace of 0x with something like a0 or by removing the character x from the list of available characters.

This is no theoretical topic: wp_generate_password() is used sometimes to create api access keys. We know from one client that one of his access keys created by wp_generate_password() led to a completely break of his application because his access token was a string like 6zx0XF5CzCqwkKu2RbKU9KuCtEV0OR6uyBcw4BZx345345345QPzBj

A password, as it is user input should never contain a phrase like 0x if you want to make sure the generated string will pass security modules.

[peterwilsoncc]

Thanks for the report @ReneHermi

This seems like a bug with mod security, I can see their developers ​merged a fix last year reduce the false positives.

Are you able to provide the following:

• is this issue occurring on the current release of mod security?
• if a password begins with 0x... does the module prevent users logging in?

[ReneHermi]

is this issue occurring on the current release of mod security?

I could not test this as it is a client-server

if a password begins with 0x... does the module prevent users from logging in?

No, this works. I verified it a moment ago. So, this does not seem to affect the wp core as I initially thought and seems to be a rare edge case. I am closing the ticket.

Thanks @peterwilsoncc

[peterwilsoncc]

Thanks @ReneHermi,

I remembered overnight that the characters are three or more hexadecimal characters.

When you were testing the WordPress password, did you include anything outside of [a-f0-9] in the first three characters after the 0x? If so, would you be able to test with something like 0xa4detc,etc as the password?

Thanks for your help with this, I don't have access to a server with mod security so I really appreciate your testing.

[ReneHermi]

I am not able to break the login even with this particular password combination which is good but can reproduce and cause always a "fatal error" on the client website by adding a URL with this character combination into the URL bar:

​https://example.com/?test=0xa4detc
while changing the 0x to something different always returns the site properly:
​https://example.com/?test=1xa4detc

The fatal error is 418 which indicates it has been generated by mod_security:

I could imagine that this behavior could lead to further implications, (even though its very specific), maybe with the REST API and other public endpoints so could be worth watching this more closely whenever a server responds with something unexpected.

If you want me to test something more, just let me know.

[peterwilsoncc]

Thanks for following up again.

Given it is working with passwords, I think your decision to close was for the best. Preventing certain combinations of passwords that work seems unwise.

When adopting the function for other purposes, I suggest something like this to avoid problems:

<?php
do {
  $password = wp_generate_password();
} while ( str_starts_with( $password, '0x' ) )

str_starts_with is available in PHP 8.0 and WP 5.9 and above. Also, please test my code above in case I've had a brain fade :)