开发者

Is the client allowed to choose challenge (nonce) in Digest HTTP authentication?

开发者 https://www.devze.com 2023-02-09 16:52 出处:网络
Digest authentication looks like a flavor of challenge-response mechanism: theres\'s a random string which is mixed with the password (MD5 or something) by both the client and the server and only the

Digest authentication looks like a flavor of challenge-response mechanism: theres's a random string which is mixed with the password (MD5 or something) by both the client and the server and only the result of such mixing is sent over the network.

Usually the challenge ("nonce") is chosen by the server and sent to the client. Wikipedia article on digest authentication lists a sample "session" - the challenge ("nonce") is chosen by the server there. I tested the same with IIS on my machine - again, the challenge is generated by IIS.

But in some posts like this 开发者_如何转开发one the challenge is generated by the client - the client just generates a random string and sends a request with the challenge and the product of the password and that challenge.

Is the latter allowed and widely accepted? Is the client allowed to choose the challenge ("nonce")?


In HTTP digest authentication, the server always generates the nonce.

However, HTTP authentication is extensible, and applications may implement other methods of authentication (beyond basic and digest). In the example you link to, the client is authenticating using WSSE, a form of authentication for (mainly SOAP-based) web services. In WSSE, the client generates the nonce.


The Digest Access Authentication scheme is only a one-way authentication where the client authenticates itself to the server but not vice versa. Only the server issues a challenge that the client needs to be responded to correctly to be authenticated. So only the server knows if the client is authentic but the client doesn’t know if the server is authentic.

Now the linked code does the exact opposite: The client issues a challenge to the server to authenticate it. So the client knows if the server is authentic.

The best would be to use mutual authentication.

0

精彩评论

暂无评论...
验证码 换一张
取 消