specs
specs copied to clipboard
Using SHA256 Hashing algo for http digest authentication in ONVIF Device Test Tool instead of MD5 since MD5 is insecure
onvif ext ticket - 2239 is already logged for this work item.
https://wush.net/trac/onvif-ext/ticket/2239
As Per suggestion from Sujith, I am logging the issue here.
Currently latest ONVIF Device Test Tool use MD5 hashing algo as part of HTTP Digest authentication feature verification which makes ONVIF Device(s) mandatorily support MD5 hashing as part of http digest authentication in device side and MD5 hashing is vulnerable and insecure.
The point here is lets allow ONVIF device to support either MD5 or SHA256 or both hashing algos and It is up to the ONVIF device vendor what hashing algo(i.e Md5 or SHA256) the device can support, do not mandate every ONVIF device should support MD5 Hashing in digest authentication as part of ONVIF Specification.
Currently ONVIF device communicates to ONVIF client what hashing algo the device can support as part of HTTP Digest challenge(i.e 401 unauthorized). If the device reports MD5 hashing algo , then client can use MD5 hashing in digest authentication. And if device reports SH256 hashing algo, then client can use SHA256 hashing algo. If device supports both i.e MD5 & SHA256, device can report same in digest challenge, client can choose either one i.e MD5 or SHA256 what it can support. This way we can solve compatibility issue(I mean we are not forcing ONVIF device vendor to support SHA256 here) and gave more chance to ONVIF Device vendor(s) to choose what hashing algos they are interested(i.e concerning about their device security) and they can support in their devices.
I tried to look and access https://wush.net/trac/onvif-ext/ticket/2239 and was refused access.
I have been interested in this topic and is being actively discussed with the VE Working group.
onvif-ext is a separate wush repo that you need to be granted access to. Check with Hans if can add you.
@HansBusch can I please be granted access to the onvif-ext wush repo please.
PR #237 resolves this issue. Closing this issue based on 8/18 Telco.