Hi Mike, thanks for the additional info.
Session auto-renew is a core feature of the session system and was deliberately designed the way it is with all trade-offs in mind. So this isn’t some long-forgotten niche thing that we can purge quickly. That said, I appreciate that security is important and we can do better and I appreciate the initiative :) My concern to some degree is the usability that is a combination of session auto-renew and session timeout. Our current default session timeout is 10 minutes. When working on CouchDB through Fauxton, you barely notice the 10 minutes, because if you’re active in the renew period, you never(!) have to log in again. That said, one usually works on Fauxton and other systems and if you get sucked into something else for 12 minutes, then your Fauxton session expires, and Fauxton doesn’t handle that fact very gracefully, losing all state and only partially drawing the current screen if it includes resources that now 404 for you. This behaviour works well enough that in practice, folks don’t raise their session timeout, which is a good thing™. If folks had to log in every 10 minutes regardless of their activity, they’d raise the limit much sooner which is also not preferable from a security perspective. This all to say, I don’t feel strongly about the implementation of this, but I do feel strongly about the user experience in Fauxton in the sense that it should work well and shouldn’t lead users to lengthen the session timeout out of spite. The minimum change I’d request if we were to disable session auto- renew, or make it an option, is that we make Fauxton smarter with session timeouts. I’d imagine the networking layer raising a modal on 401s which keeps the rest of the app state as-is, so I can go to lunch and finish editing my design doc without losing anything. And just to make clear: I am NOT advocating that an infinite session is a good thing and I AM saying that the current design is deliberate rather than an oversight, or in some for niche. Best Jan — > On 21. Dec 2018, at 10:38, Mike Rhodes <couc...@dx13.co.uk> wrote: > > Jan, > > A server-side mechanism would be good too, and covers some of the problem > space but I'm not convinced it covers all use of cookies. > > I should've outlined my problem, so taking a step back: logging out doesn't > invalidate the session cookie. Combined with auto-renew, this gives you a > security problem. > > I think the easiest way, from a code perspective, to mitigate this is to > remove auto-renew. Perhaps optionally given its long existence 🙂 > > I think Jan, that you are right that invalidating cookies on log out is > preferable to disabling auto-renew. However, this only covers the browser > case satisfactorily in my mind. Neither the replicator nor client > libraries[1] have a "logout" option, and, while grabbing cookies from a > server-side app is a bunch harder I wanted to mention that risk. Perhaps the > solution here is to have an alternative to cookies for "fast" authn for > machine clients, reserving cookies for browsers. > > Does anyone have opposition to an option to disable this behaviour via config? > > [1]: At least exposed in such a way -- say via a "close"-type method -- that > I might remember to use. > > -- > Mike. > > On Thu, 20 Dec 2018, at 16:42, Jan Lehnardt wrote: >> Cookie persistence is separate from auto-renewing sessions. >> >> The former makes cookies survive the closing of a browser (window), the >> latter is the behaviour Mike outlined correctly in the original mail. >> That feature was introduced when _session was added in the 0.x days, so >> it’d be a big change. >> >> I think we have some vague plans to move to a server/cluster managed session >> solution eventually, at which point we’d be able to terminate sessions from >> the server end without changing the password or anything. >> >> I’d say that would be more desirable than flat out killing auto-renew. >> >> Best >> Jan >> — >> >>> On 20. Dec 2018, at 17:21, Joan Touzet <woh...@apache.org> wrote: >>> >>> Looks like the original code that introduced the option was done as part >>> of this work: >>> >>> https://issues.apache.org/jira/browse/COUCHDB-1304 >>> >>> One serious concern on disabling this by default is what might happen >>> to the replicator performance improvement introduced in 2.2.0: >>> >>> https://github.com/apache/couchdb/pull/1619 >>> >>> Nick, can you answer what happens to the replicator if we >>> disable allow_persistent_cookies by default? Do we lose the expires >>> header you need to successfully refresh, or did we fix that in 2.3.0? >>> My memory is poor. >>> >>> -Joan >>> >>> ----- Original Message ----- >>> From: "Jonathan Hall" <fli...@flimzy.com> >>> To: dev@couchdb.apache.org >>> Sent: Thursday, December 20, 2018 11:01:10 AM >>> Subject: Re: [PROPOSAL] Disable auto-renew of _session cookies >>> >>> The behavior you request is actually the default behavior. I ran into this >>> when I was expressly seeking the behavior you're trying to disable, and >>> made a feature request, only to learn that it is indeed configurable. See >>> this issue: https://github.com/apache/couchdb/issues/1598 >>> >>> In short, I believe that you simply need to disable the >>> allow_persistent_cookies option in your configuration. >>> >>> >>> >>> On December 20, 2018 1:42:18 PM GMT+01:00, Mike Rhodes <couc...@dx13.co.uk> >>> wrote: >>>> Hi, >>>> >>>> Currently, _session cookies auto-renew. From what I can read of the >>>> code, I think this is via [1] calling into [2], which will put a >>>> Set-Cookie header on the response. >>>> >>>> What this means, I think, is that if I can retrieve your session cookie >>>> in some way, then ensure I keep making calls within the expiration time >>>> of the original cookie and it's auto-renewed descendants, I have an >>>> ever-lasting way to access your CouchDB data. >>>> >>>> (Nearly everlasting, anyway, as the password update process will change >>>> the password hashing salt which forms a part of what the cookie's >>>> signature signs over. Nonetheless, this requires the user notice the >>>> compromise and update their password to invalidate existing sessions. >>>> For many attacks, it easy to get valuable data without tripping alarm >>>> bells.) >>>> >>>> As far as I can see, this isn't a configurable option. What are the >>>> thoughts of the list for removing the auto-renew function given its >>>> security risks? From what I understand, this has been CouchDB's >>>> behaviour ~forever, so I can see perhaps it's a risky change. >>>> >>>> [1]: >>>> https://github.com/apache/couchdb/blob/be6de6f32d0be7147dce8ebe39dd54c07d7be31f/src/chttpd/src/chttpd.erl#L1140 >>>> [2]: >>>> https://github.com/apache/couchdb/blob/1347806d2feebce53325070b475f9e211d240ddf/src/couch/src/couch_httpd_auth.erl#L246 >>>> >>>> -- >>>> Mike. >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >> -- >> Professional Support for Apache CouchDB: >> https://neighbourhood.ie/couchdb-support/ >> >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
