It could. I proposed different solutions before to the mailing list (without any replies). The impact would be about:

• Add a module parameter "algorithm" that allows configuring "SHA-256" instead of "MD5"
• Add SHA-256 versions for the functions calc_HA1 and calc_response (similar to rfc2617.c/h) and add two function pointers that can either point to the MD5 or SHA256 implementations, depending on the config.
• Use the function pointers in the functions auth_s, auth_check_response and pv_authenticate where calc_HA1 or calc_response are used.
• In the function auth_check_response replace HASHHEX allocated on the stack by at least char[65] and compare the length of the credentials provided by the client dynamically depending on the config (32 for MD5, 64 for SHA-256).
• Provide the configured algorithm to the two calls to get_challenge_hf to build the challenge header field with the desired algorithm.

The defines for HASHLEN, HASHHEXLEN, HASH and HASHHEX are tricky. The are also also used in the API but must be doubled in size to account for the hash value that is twice as long in for SHA-256.

Would you prefer this solution ? If yes, I'll propose an implementation. We would certainly be happy if the SHA-256 feature is directly part of the auth module.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub