Enhance wp_hash function to support custom hashing algorithms

[pushpenderindia]

Currently In wp_hash function, it has hardcoded the hashing algorithm i.e. md5, but as we know, that md5 is an unsecure algorithm & is vulnerable to collision attacks.

So the aim of this PR is to enhance the wp_hash function, so that user can supply secure custom hashing algorithm such as sha256, while they were building Plugins or Themes.

If the $algo argument is not supplied then it should fallback to md5, just to support backward compatibility.

Following are some more details about this new feature enhancement:

Summary
This PR updates the wp_hash function to allow users to specify a custom hashing algorithm, enhancing the security and flexibility of the function. Previously, the function hardcoded the md5 algorithm, which is vulnerable to collision attacks.

Changes:

Added a new parameter $algo to the wp_hash function, allowing users to specify the hashing algorithm.
The default remains md5 for backward compatibility.
Implemented a check using hash_hmac_algos() to ensure the provided algorithm is supported. If not, the function will fall back to md5.

Benefits:

Users can now choose more secure hashing algorithms like sha256.
Improved security by allowing the use of modern, collision-resistant hashing algorithms.

Backward Compatibility:

The function retains md5 as the default algorithm, ensuring backward compatibility with existing code.

Testing:

Tested with various algorithms (md5, sha256, sha512) to confirm correct functionality.
Validated fallback to md5 when an unsupported algorithm is provided.

Trac ticket: https://core.trac.wordpress.org/ticket/62005

### Summary
This PR updates the wp_hash function to allow users to specify a custom hashing algorithm, enhancing the security and flexibility of the function. Previously, the function hardcoded the md5 algorithm, which is vulnerable to collision attacks.

### Changes:

• Added a new parameter $algo to the wp_hash function, allowing users to specify the hashing algorithm. The default remains md5 for backward compatibility.
• Implemented a check using hash_hmac_algos() to ensure the provided algorithm is supported. If not, the function will fall back to md5.

### Benefits:

• Users can now choose more secure hashing algorithms like sha256.
• Improved security by allowing the use of modern, collision-resistant hashing algorithms.

### Backward Compatibility:

• The function retains md5 as the default algorithm, ensuring backward compatibility with existing code.

### Testing:

• Tested with various algorithms (md5, sha256, sha512) to confirm correct functionality.
• Validated fallback to md5 when an unsupported algorithm is provided.

[ayeshrajans]

I think this is a good improvement.

The only suggestion I have is to throw an exception on non-hmac hashing algorithms instead of silently falling back to md5. This is security-sensitive code, and we should be more cautious and not forgiving.

[pushpenderindia]

Replying to ayeshrajans:

I think this is a good improvement.

The only suggestion I have is to throw an exception on non-hmac hashing algorithms instead of silently falling back to md5. This is security-sensitive code, and we should be more cautious and not forgiving.

I've updated the code, now it will throw an exception on non-hmac hashing algorithms

[pushpenderindia]

Hi @ayeshrajans , Now all the checks are passing and I've implemented the patch correctly as per your suggestions, I kindly request to review it and approve the changes.

[johnbillion]

@pushpenderindia This seems like a sensible change. Out of interest do you have any concrete use cases for this change?