Re: Should the Django session-id be hashed?

Hi Everyone, I took a stab at implementing this. I'd appreciate any feedback on the PR . The 8tracks leak over the weekend highlights the importance of hashing session ids. The attacker o

Re: Should the Django session-id be hashed?

On 22 Sep 2016, at 20:32, James Bennett wrote: > So personally I'd like to hear some more about why this is seen as necessary > before I'd endorse work to actually implement it. The reason why I originally filed a security report is that session stores tend to have less focus on security than

Re: Should the Django session-id be hashed?

For what it's worth, I'm suspicious of threat models which begin with "assume the DB has already been significantly compromised..." simply because there's so much someone can do if they gain even read access that it's not worth expending a ton of effort hardening Django against those cases. Simila

Re: Should the Django session-id be hashed?

Sure, go ahead. On Thursday, September 22, 2016 at 9:31:35 AM UTC-4, Violet Gibson wrote: > > Thanks for ticket link. > > Would you mind if I assigned it to myself? I have a few ideas on how > it could be put together, and I'd like to work on it tonight and > submit a proposal. > > Rigel. > >

Re: Should the Django session-id be hashed?

Thanks for ticket link. Would you mind if I assigned it to myself? I have a few ideas on how it could be put together, and I'd like to work on it tonight and submit a proposal. Rigel. On Thu, Sep 22, 2016 at 2:23 PM, Tim Graham wrote: > The idea of adding an option to store the session ID hash

Re: Should the Django session-id be hashed?

The idea of adding an option to store the session ID hash rather than the ID itself was discussed a few years ago on the core team mailing list (see the "Authentication best practices" thread and "Don't store session IDs in the clear" in the security issue tracker). Maybe we can reproduce some o

Re: Should the Django session-id be hashed?

> Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor : > > If Django were a different framework, I'd probably think this was a > reasonable idea. However, Django's ORM is _incredibly_ good at deterring SQL > injection. In many many years of using and reviewing Django applications, SQL > injection i

Re: Should the Django session-id be hashed?

On Thu, Sep 22, 2016 at 12:31 PM, Curtis Maloney wrote: > They're just a random string, I don't see how turning them into another > random string will help? Or do you mean to set the original string in the > cookie only, and hash them for the key, and hash them _every_ _time_ you > look up the se

Re: Should the Django session-id be hashed?

I have noticed that session id's are included in Django debug emails, with no clear way to filter them out. I'm unsure of the behaviour with 1.9+, but this is what I've experienced with 1.8. The way around that issue though is to sign the cookie, so that people can't just drop the session-id in.

Re: Should the Django session-id be hashed?

If Django were a different framework, I'd probably think this was a reasonable idea. However, Django's ORM is _incredibly_ good at deterring SQL injection. In many many years of using and reviewing Django applications, SQL injection is vanishingly rare in my experience; therefore I think this adds

Re: Should the Django session-id be hashed?

On Thursday, September 22, 2016 at 1:26:19 PM UTC+2, Violet Gibson wrote: > > Unless I'm missing something, these ids could be > vulnerable to SQL injection attacks, if any are discovered or if > developers misuse features like extra(). Same is true for literally any field a user can write in

Re: Should the Django session-id be hashed?

On 22/09/16 18:52, Rigel wrote: Hello! The Django session framework stores session-ids in the database as plain-text. Unless I'm missing something, these ids could be vulnerable to SQL injection attacks, if any are discovered or if developers misuse features like extra(). Firstly, extra() is

Should the Django session-id be hashed?

Hello! The Django session framework stores session-ids in the database as plain-text. Unless I'm missing something, these ids could be vulnerable to SQL injection attacks, if any are discovered or if developers misuse features like extra(). This vulnerability could be mitigated if the session-ids