Improve security of wp_nonce implementation

[chaoix]

The current wp_nonce implementation is a little out dated and should be improved. While nonces aren't security, a strong nonce implementation can provide some security against form field manipulation.

I have attached a mu-plugin I wrote to test a new nonce algorithm. I will convert it to a patch if there is interest in improving this in core. I have been running this mu-plugin on several high traffic sites I manage with no issues for over 6 months now.

[chaoix]

Secure WP Nonces mu-plugin

[johnbillion]

Thanks for the ticket @chaoix.

Can you provide some information about the algorithm and the changes you've made from core's current implementation please? What aspects make it more secure? Do you have any test coverage? etc.

Thanks

[knutsp]

I have tested the attached plugin for a month on four sites. No issues observed, except that it reports undefined variable $value in line 40.

[johnbillion]

@chaoix Any update on the above? This is a mystery change without more information from you :-)

[chaoix]

I have provided an updated implementation of my changes to the nonce algorithm with more detailed comments.

The benefits of these changes are:

• Uses the sha512/sha256 hashing algorithm for increased nonce length and performance improvements with longer nonce actions. Longer actions prevent brute forcing of the nonce for known action names. MD5 was the previous hashing algorithm used and is not secure enough for what nonces are being used for in WordPress. ​https://en.wikipedia.org/wiki/MD5#Security
• Adds complexity to the nonce hash algorithm to make them more difficult to reverse engineer using rainbow tables.
• Adds a browser id to the nonce action to help prevent known hash reuse.
• Reject nonces from browsers with no or invalid user agent strings. This will prevent lazy bots from submitting requests.

I have had these changes running live on 4 higher traffic sites with no issues. I have not run or made any unit tests for these changes.

[kkmuffme]

I think this is definitely something that could be added easily, however the PR needs a bit of work.

• Why do you hash the user agent, when you then hash everything later on anyway?
• the user agent might not be set if the request comes from PHP CLI, atm this produces a notice in the patch
• redudant code line 26/27?
• always use SHA512, since it's faster
• why truncate to 64 characters?
• hash_hmac seems useless as well as the explode making it unnecssarily complex/slow
• duplicate code with the user agent in 2 functions