You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Mike Rhodes <co...@dx13.co.uk> on 2018/12/20 12:42:18 UTC
[PROPOSAL] Disable auto-renew of _session cookies
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.
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Jan Lehnardt <ja...@apache.org>.
Cute idea, but I’m not necessarily speaking for myself here,
but the average CouchDB user. CouchDB ships with Fauxton and
that’s the experience I’m concerned about.
Best
Jan
—
> On 21. Dec 2018, at 19:20, ermouth <er...@gmail.com> wrote:
>
>> so I can go to lunch and finish editing my design doc without losing
> anything.
>
> Consider using Photon https://github.com/ermouth/couch-photon
>
> ermouth
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by ermouth <er...@gmail.com>.
> so I can go to lunch and finish editing my design doc without losing
anything.
Consider using Photon https://github.com/ermouth/couch-photon
ermouth
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Jan Lehnardt <ja...@apache.org>.
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 <co...@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 <wo...@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" <fl...@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 <co...@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/
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Mike Rhodes <co...@dx13.co.uk>.
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 <wo...@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" <fl...@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 <co...@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/
>
>
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Jan Lehnardt <ja...@apache.org>.
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 <wo...@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" <fl...@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 <co...@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/
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Nick Vatamaniuc <va...@gmail.com>.
Good point regarding the replicator session refresh, Joan. I think it
should continue to work, but there would be a slight performance loss. Each
replication would make a new request to _session every 10 minutes or so (by
default), when now it gets a new session cookie for "free" so to speak.
To review, currently a cookie refresh in the replicator happens in these
cases:
1) Auth / Authorization requests fail. Then we try to get a new session
cookie from _session. With auto-refresh this is not that used I imagine. It
does involve making an extra request (make original request, fail, refresh
cookie, retry request). And also this doesn't work if endpoints allow
anonymous writes.
2) max-age in the cookie value is about to expire (over 90% expired). We
also enabled allow_persistent_cookie=true by default, as you mentioned, so
most recent endpoints should send max-age now. Without auto-refresh this
would hopefully become the best method to do refresh.
3) If max-age cannot be parsed we still get a new cookie at close to
default expiry interval for CouchDB (550 seconds) This accounts for
endpoints which haven't upgraded to the latest release, but just happened
to have session expiry defaults (600 seconds).
4) Response headers return a new session cookie. In that case we'd
remember the cookie as the new session cookie. But if we decide not to do
that anymore. In that case the other 3 conditions would hopefully be enough
to perform the refresh.
Cheers,
-Nick
On Thu, Dec 20, 2018 at 11:21 AM Joan Touzet <wo...@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" <fl...@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 <co...@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.
>
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Joan Touzet <wo...@apache.org>.
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" <fl...@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 <co...@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.
Re: [PROPOSAL] Disable auto-renew of _session cookies
Posted by Jonathan Hall <fl...@flimzy.com>.
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 <co...@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.