Daniel-Constantin Mierla writes:
I am not sure if this option is actually implemented according to the specs. iirc, stale=true should be set when the server checks the username and password and all is ok, but the nonce is expired. afaik, the check for nonce expiration is done before hiting the database to fetch the password and check the response.
Is there a function for doing the nonce check or is www_authorize doing it before making db query?
In UA side the stale=true would just make the app rebuild the response without prompting for password again, because the server said that with the expired nonce all was ok, from user/password point of view.
That is exactly the point of stale=true.
But if we hit the database for every expired nonce, then we expose the server to kind of a DoS processing.
It is possible to use, e.g., fail2ban, also in expired nonce case.
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
I agree with that, but in case of expired nonce, the sender already has somehow figured out what the username is.
The lack of stale=true means that the UA should build again the authorization header from scratch with all the attributes.
And ask the user for password again, which is not a good idea.
I won't be against enabling this option if it would be for a "trusted" endpoint, but for servers exposed to the wild world, it may create some security concerns.
Therefore for the moment I would suggest to wait for more feedback from community, along with checking if the stale=true is implemented as per spec or is half brewed option.
The spec says:
"If stale is FALSE, or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid and new values must be obtained."
As I already mentioned, not a good idea to keep asking password all the time.
-- Juha