Username with empty password authentication...

[tommys]

Hi,

I'm currently testing my OPC UA Server, based on latest UA C++ Server SDK, for certification using CTT by OPC Foundation.

Two of their test cases fail due to an unexpected response when they supplied an empty password! Specifically, in their 005.js and 006.js of the test suite: "Security User Name Password", they authenticate using UserNameIdentityToken. In both test cases CTT supplies an empty password. CTT either expects Good, but we do not allow that, or they expect BadIdentityTokenRejected. Unfortunately, our OPC UA Server returns BadInvalidArgument in both cases. Hence certification test fail, which is not good.

Looking at the code, I see that UaPasswordManager always return OpcUa_BadInvalidArgument in its checkAuthentication method when password size is zero! This method is not virtual so I cannot override and tweak the behaviour so I have to patch the code to return OpcUa_BadIdentityTokenRejected instead. Doing that and then re-run CTT solves the issue, and both 005 and 006 tests pass. :-)

I re-read the OPC UA Specification and from my understanding CTT is more right than UA since the specification explicitly states that zero length passwords are allowed, therefore an empty password should not be considered as an invalid argument.

Regards,
/Tommy

[Support Team]

Hi,

we are in discussion with OPC Foundation to allow both status codes, because the InvalidToken is also pointing in the wrong direction, because the "token" was correct (it was user/pwd), but just the pwd was "wrong" (hence PermissionDenied would be another option), but in fact the "empty" pwd is an InvalidArg when looking from the perspective of the validation function. So finally InvalidArg is very close to what is the real error. That said, the test lab currently accept both status codes. It the PWD is to long, to short, not complex enough, it is kind of "invalid" syntactically.

However we agree that some clarification is needed on this one.

[tommys]

Ok, I kind of agree with your reasoning. Good that you already raised this issue with OPC Foundation.
Thank you!

Regards,
/Tommy

[Support Team]

Hi,

we think that the "PermissionDenied" most probably is the best return in this case (wrong password). In addition the "TokenRejected" is some alternative return, saying pretty much the same (content of Token is wrong). Both return codes are accepted by the CTT compliance testing. However to prevent timing/oracle attacks the server should return same error at same timing to not give the attacker (brute force) any hints.

Therefor it is important that you map the internal User/Pwd Manager API's return code to the correct OPC UA StatusCode returned over the wire. The UaDemoServer is doing exactly that, but you must check your own implementation (application specific implementation of password manager may behave differently).