As a matter of fact, in the absence of these checks, an attacker that can sniff an unencrypted ONVIF interaction would also be able to indefinitely replay the credentials in new requests towards the camera, which would be accepted as valid authenticated requests by the device. Although only “recommended” by the specification, it is crucial that the device correctly validates all these counter measures for security-critical requests. The specification steps can be considered optional to relieve the device from the burden of performing the verifications for non-sensitive, non-state changing requests. It is recommended that used nonces be cached for a period of time at least as long as the timestamp freshness limitation period, above, and the UsernameToken with nonces that have already been used (and are thus in the cache) being rejected. As a guideline, a value of five minutes can be used as a minimum to detect, and thus reject, replays.ģ. It is recommended that web service producers provide a timestamp “ freshness” limitation, and that any UsernameToken with “ stale” timestamps be rejected. It is recommended that web service producers reject any UsernameToken not using both nonce and creation timestamps.Ģ. According to the ONVIF standard, for web service producers to effectively thwart replay attacks, three counter measures are also recommended (where “recommended” is to be interpreted according to RFC 2119 parameters):ġ. This helps obscure the password and offers a basis for preventing replay attacks. This is the resulting digest to be included in the request to authenticate it: Setting a password generates a “PasswordDigest,” a digest that is calculated according to the following algorithm:ĭigest = B64ENCODE( SHA1( B64DECODE( Nonce ) + Created + Password ) )
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |