What should do when client provide non-exist userid?

[SunFulong]

If router require authenticate, the Client send hello message with a valid realm and non-exist userid, should the router reply ABORT message or continue CHALLENGE progress and then ABORT it after AUTHENTICATE?

[ecorm]

It is better from a security standpoint to not give any information that would allow an attacker to determine if a userid exists (e.g. "root" or "admin"). Thus, it is more secure to proceed as if the userid exists, issue the CHALLENGE, and then fail after AUTHENTICATE.

See https://security.stackexchange.com/questions/17816

There is the wamp.error.no_such_principal error URI in the spec, but I would never personally use it for this purpose in my apps. I would just report wamp.error.authentication_denied.

[SunFulong]

The spec only said: To request authentication, the Router MUST send a CHALLENGE message to the Endpoint., so I don't know can I just reply ABORT with wamp.error.no_such_principal

[ecorm]

so I don't know can I just reply ABORT with wamp.error.no_such_principal

The statechart shows that you can send an ABORT immediately after receiving a HELLO, as well as the example given under ABORT.

The spec doesn't go into detail about which error URIs are permitted in an ABORT in response to a HELLO. I don't think there would ever be a consensus on exactly which error URIs are permitted in that scenario.

I'll reiterate that it's not advised to give away information that allows an attacker to determine if a username exists.

[SunFulong]

The statechart shows ...

Yes, but it is under basic profile, the advance profile section WAMP-level Authentication said To request authentication, the Router MUST send a CHALLENGE message to the Endpoint., so i'm confused.

I'll reiterate that it's not advised to give away information that allows an attacker to determine if a username exists.

I know the security things, but it will take extra costs for cloud compute.

[ecorm]

Yes, but it is under basic profile

That statechart also includes the CHALLENGE and AUTHENTICATE messages. When the statechart was added to the spec (I'm the one who contributed that statechart in graphical format, by the way), we didn't bother to make two versions for the basic and advanced profiles.

To request authentication, the Router MUST send a CHALLENGE message to the Endpoint., so i'm confused.

"To request authentication" means that the router wants to request authentication. The router requests authentication by sending a CHALLENGE, where it expects an AUTHENTICATION in response. The client can only ask for authentication methods in its HELLO message.

I can see how it could be confusing the way it's currently worded, so perhaps this could be clearer:

A Router desiring authentication MUST send a CHALLENGE message to the Endpoint Client.

I guess it also wouldn't hurt to add a clause in that section that says a Router MAY send an ABORT in response to a HELLO if, for example, the client failed to provide adequate credentials.

There should also be a clause added that says multiple CHALLENGE/AUTHENTICATION exchanges are permitted if the authentication method requires more than one exchange. The spec currently doesn't have any such auth methods that need multiple rounds of CHALLENGE/AUTHENTICATION, but we should make it possible to include them in the future, if needed.

That is my interpretation, but I don't pretend to speak for others who were involved in the writing of those sections.

[KSDaemon]

I think @ecorm Provided all the details. So I can only agree :)

[SunFulong]

Thanks a lot, I'll implement it by send ABORT after HELLO.

[ecorm]

I think this should be raised as an issue so that the specification is clarified a bit.

[oberstet]

We could add @ecorm notes under "security considerations" or under the CHALLENGE/AUTHENTICATION section, or under the general ABORT / state machine section ...