Open hugeice opened 8 years ago
The nonce is passed to the validate
callback. Is that not sufficient for detecting replay attacks?
Sorry, I did not express clearly.
1, The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value. However, in current implementation of passport-http, the nonce value in challenge has not been saved. Therefore, we can not know whether the authentication request corresponds to the challenge we sent before, which may not conform to the challenge-response paradigm. Of course, if the digest values match the nonce, it indicates that the client knowns user password or HA1 value, which may not cause any security issues.
2, Although you can check the nonce in validate callback. However, to prevent replay attacks, the server must save all used nonce values to detect any repeated/reused nonce value. This is more complex, and with time gose by there will be more and more nonce values which may take too many resources in server side. As an alternative, if we allow the user to generate nonce value, users will have more choices to achieve additional checks, even without relying on the saved nonce values. For example: user can generate a nonce with server timestamp using some algorithm, and retrieve the server timestamp from the nonce value received from client. Then user can further checks whether the timestamp is within the allowable range. Similarly, the client IP address can be also added to the nonce generation algorithm. Reference: RFC2617 "4.5 Replay Attacks"
Add a callback function to the options, so that the user can control the nonce field in challenge and perform additional validation for the nonce, thereby preventing replay attacks.