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 _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
