full-disclosure - Re: [Django] Cookie-based session storage session invalidation issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 3 Oct 2013 16:32:54 -0400
From: "G. S. McNamara" <main@...cnamara.com>
To: Paul McMillan <paul@...illan.ws>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Django] Cookie-based session storage session
 invalidation issue

Now that we're in agreement about the vulnerability and are getting off
topic, I think this thread has run its course. If you have an issue with me
let's spare the FD subscribers and you can contact me directly.

Thanks!

G. S. McNamara

On Thu, Oct 3, 2013 at 4:12 PM, Paul McMillan <paul@...illan.ws> wrote:

> The technical properties of the feature (entirely client-side
> sessions) require this behavior. As you rightly pointed out, this
> brings with it some limitations, including the inability to
> prematurely expire a session. This, and other properties of this
> session backend are why it is not the default backend, and why there
> are explicit warnings about it. Nevertheless, it is useful in some
> deployment scenarios. I agree that the current even more explicit
> warning is better.
>
> You might want to include a recommendation for shorter session
> timeouts in your blog post, since that works relatively well to combat
> this problem in deployments which require client-side sessions.
>
> On Thu, Oct 3, 2013 at 8:34 PM, G. S. McNamara <main@...cnamara.com>
> wrote:
> > Not sure why all the hostility.
>
> You write a blog post, and post to FD, waving around a "newly
> discovered vulnerability" that was a carefully and deliberately chosen
> design decision made during the implementation of the feature.
> Furthermore, you didn't have the decency to email the project security
> alias to inquire about this until the day after posting about it
> publicly. This is FD, so I'm not going to comment further on that
> behavior, but perhaps you can imagine why your praises are not being
> sung particularly loudly.
>
> -Paul
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/