Should the Django session-id be hashed?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Should the Django session-id be hashed?

Rigel
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 were hashed with a secure cryptographic
hash function, like SHA-256, before storing them or querying for them
in the database.

This concern has recently been raised for Joomla! on the Full
Disclosure mailing list:
http://seclists.org/fulldisclosure/2016/Sep/50

What is your opinion on this matter? It could be fairly trivial to
implement, with the only side effect of being computationally
expensive. Still, security is more desirable than efficiency or
performance.

Rigel.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAD9P0Jr-pYSM%3DJkwiWoNg-BbfFbCxYW5ucbPy_dwssbiXS1d3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Curtis Maloney-2


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 on is way out... being replaced by expressions,
transforms, and so on...

That said, yes, extra() does potentially open you to SQL attacks, but
only if you use it incorrectly.  If used as documented -- same goes for
raw() -- you should remain immune to SQL injection.

The only time you're likely to become vulnerable to SQLi is when you do
something as stupid as putting values into SQL commands yourself.

> This vulnerability could be
> mitigated if the session-ids were hashed with a secure cryptographic
> hash function, like SHA-256, before storing them or querying for them
> in the database.

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 session?

> This concern has recently been raised for Joomla! on the Full
> Disclosure mailing list:
> http://seclists.org/fulldisclosure/2016/Sep/50
>
> What is your opinion on this matter? It could be fairly trivial to
> implement, with the only side effect of being computationally
> expensive. Still, security is more desirable than efficiency or
> performance.

You are right there, security is more important.

However, it's a small overhead for everyone... for a small win for
almost nobody.

Until you can demonstrate how there's any SQLi vulnerability, I'm -1 on
this.

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16ef8ea5-cc5c-ad81-bdf8-f2d6f438bb61%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Florian Apolloner
In reply to this post by Rigel


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 into.
 
What is your opinion on this matter?

Not worth it imo,

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3c8e5034-b0ed-4dbc-b60c-a2f9b280926e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

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 is vanishingly rare in my experience; therefore I think this adds complexity for limited gain. Another relevant factor is that this is only applicable to the database sessions backend.

Alex

On Thu, Sep 22, 2016 at 7:33 AM, Florian Apolloner <[hidden email]> wrote:


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 into.
 
What is your opinion on this matter?

Not worth it imo,

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3c8e5034-b0ed-4dbc-b60c-a2f9b280926e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFRnB2V0fcmfR1Z7Actbs4%2Bxh_pwzooq6uEes%3Ds6K_L%3DUYMehg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Anthony King
In reply to this post by Florian Apolloner
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.

On 22 September 2016 at 12:33, Florian Apolloner <[hidden email]> wrote:


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 into.
 
What is your opinion on this matter?

Not worth it imo,

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3c8e5034-b0ed-4dbc-b60c-a2f9b280926e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALs0z1Y3QmWivi72ym0pYf5-fhBDVdD7zQGN5oJk8BVNCPdWpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Rigel
In reply to this post by Curtis Maloney-2
On Thu, Sep 22, 2016 at 12:31 PM, Curtis Maloney <[hidden email]> 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 session?

I'm an attacker and I've found a way to read the session database
table. I can now impersonate user Bob.

If the session-ids were hashed, I would need still need to know's
Bob's session-id. Django woudn't store it anywhere on the database.

Rigel.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAD9P0Jr8uKogoeUz%3Dx1CHpC0hKQ4qyt5DVQo7vx-rZka7pYVyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Erik Cederstrand
In reply to this post by Alex Gaynor

> Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor <[hidden email]>:
>
> 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 complexity for limited gain. Another relevant factor is that this is only applicable to the database sessions backend.

The attacker would only need to read access for this to work, not write access. That could possibly be achieved that even without SQL injection. If the attacker can just put another person's session ID in her cookie, then session IDs are basically passwords. Passwords should not be stored clear-text. The only difference is that session IDs are more short-lived than passwords.

It's the same issue with API key authentication for REST APIs. Not many people remember to hash the keys before storing them in the DB.

If the attacker gains write access to the DB, then you're doomed anyway, hashes or not. The attacker just makes up her own session ID, hashes it and writes it to the database. Or makes up her own password and writes it to the Users table.

Erik

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/54777EE1-707B-4794-9854-394C5892587B%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Tim Graham-2
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 of that thread here if it helps. The conclusion was to create this ticket: https://code.djangoproject.com/ticket/21076

On Thursday, September 22, 2016 at 9:01:56 AM UTC-4, Erik Cederstrand wrote:

> Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1QvJ6FJtAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">alex....@...>:
>
> 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 complexity for limited gain. Another relevant factor is that this is only applicable to the database sessions backend.

The attacker would only need to read access for this to work, not write access. That could possibly be achieved that even without SQL injection. If the attacker can just put another person's session ID in her cookie, then session IDs are basically passwords. Passwords should not be stored clear-text. The only difference is that session IDs are more short-lived than passwords.

It's the same issue with API key authentication for REST APIs. Not many people remember to hash the keys before storing them in the DB.

If the attacker gains write access to the DB, then you're doomed anyway, hashes or not. The attacker just makes up her own session ID, hashes it and writes it to the database. Or makes up her own password and writes it to the Users table.

Erik

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Rigel
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 <[hidden email]> wrote:

> 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 of that
> thread here if it helps. The conclusion was to create this ticket:
> https://code.djangoproject.com/ticket/21076
>
> On Thursday, September 22, 2016 at 9:01:56 AM UTC-4, Erik Cederstrand wrote:
>>
>>
>> > Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor <[hidden email]>:
>> >
>> > 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 complexity for limited gain. Another relevant factor is that this is
>> > only applicable to the database sessions backend.
>>
>> The attacker would only need to read access for this to work, not write
>> access. That could possibly be achieved that even without SQL injection. If
>> the attacker can just put another person's session ID in her cookie, then
>> session IDs are basically passwords. Passwords should not be stored
>> clear-text. The only difference is that session IDs are more short-lived
>> than passwords.
>>
>> It's the same issue with API key authentication for REST APIs. Not many
>> people remember to hash the keys before storing them in the DB.
>>
>> If the attacker gains write access to the DB, then you're doomed anyway,
>> hashes or not. The attacker just makes up her own session ID, hashes it and
>> writes it to the database. Or makes up her own password and writes it to the
>> Users table.
>>
>> Erik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAD9P0JoLaJvOQYAGOzW3wZBNJQowmaWHpo1MfEXiqYbfXzFLOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Tim Graham-2
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.

On Thu, Sep 22, 2016 at 2:23 PM, Tim Graham <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="j0zXNfFuAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">timog...@...> wrote:

> 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 of that
> thread here if it helps. The conclusion was to create this ticket:
> <a href="https://code.djangoproject.com/ticket/21076" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F21076\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJuMWYrOy5rU6ekl1tuyo5wHl9vA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F21076\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJuMWYrOy5rU6ekl1tuyo5wHl9vA&#39;;return true;">https://code.djangoproject.com/ticket/21076
>
> On Thursday, September 22, 2016 at 9:01:56 AM UTC-4, Erik Cederstrand wrote:
>>
>>
>> > Den 22. sep. 2016 kl. 13.38 skrev Alex Gaynor <[hidden email]>:
>> >
>> > 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 complexity for limited gain. Another relevant factor is that this is
>> > only applicable to the database sessions backend.
>>
>> The attacker would only need to read access for this to work, not write
>> access. That could possibly be achieved that even without SQL injection. If
>> the attacker can just put another person's session ID in her cookie, then
>> session IDs are basically passwords. Passwords should not be stored
>> clear-text. The only difference is that session IDs are more short-lived
>> than passwords.
>>
>> It's the same issue with API key authentication for REST APIs. Not many
>> people remember to hash the keys before storing them in the DB.
>>
>> If the attacker gains write access to the DB, then you're doomed anyway,
>> hashes or not. The attacker just makes up her own session ID, hashes it and
>> writes it to the database. Or makes up her own password and writes it to the
>> Users table.
>>
>> Erik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="j0zXNfFuAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="j0zXNfFuAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
> Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> <a href="https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/e74901a8-ba03-4452-b29c-18f95e4e6f67%40googlegroups.com.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/95f5f099-322f-4e25-ada0-0396af4dda5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

James Bennett
In reply to this post by Rigel
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.

Similarly, "assume a SQL injection vulnerability already exists" doesn't do much for me because for something that lives and dies by the DB, that's very close to "assume some remote-root vuln already exists and has been exploited".

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.

On Thu, Sep 22, 2016 at 5:00 AM, Rigel <[hidden email]> wrote:
On Thu, Sep 22, 2016 at 12:31 PM, Curtis Maloney <[hidden email]> 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 session?

I'm an attacker and I've found a way to read the session database
table. I can now impersonate user Bob.

If the session-ids were hashed, I would need still need to know's
Bob's session-id. Django woudn't store it anywhere on the database.

Rigel.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAD9P0Jr8uKogoeUz%3Dx1CHpC0hKQ4qyt5DVQo7vx-rZka7pYVyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-NetD5GcA%2BjTkw0HGA0Hf8UfV4MDGRMpbSF5QT4t8aUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

Aymeric Augustin
On 22 Sep 2016, at 20:32, James Bennett <[hidden email]> 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 databases.

Of course this is a moot point when sessions are stored in the database, but I won’t start a debate about why Django still encourages this, this isn’t the point of this thread ;-)

For example Redis is well known for advertising that it has no security and should only be run within a secure network. (Defense in depth, anyone?) Still a bunch of companies provide Redis as a service, usually on random EC2 instances directly reachable from the Internet. The best ones require going through an SSL endpoint and providing a password, but an attacker can still talk directly to Redis, which is concerning given its stance on security.

In contrast, the authors of PostgreSQL have implemented an authentication and authorization framework. I’m not qualified to say if it’s robust, but at least it’s better than shrugging off security entirely.

--
Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0A4424F9-DA7B-4BB7-B558-34D4B3893CC7%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Should the Django session-id be hashed?

django-developers mailing list
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 only gained access to backups of the database. AFAIK with the current version of Django, the attacker would've been able to login as any user that hadn't been logged out by simply setting a cookie. By storing the session ids as hashes, we can effectively mitigate this attack vector.

Thanks for the feedback,

Chris

On Thursday, September 22, 2016 at 2:41:22 PM UTC-4, Aymeric Augustin wrote:
On 22 Sep 2016, at 20:32, James Bennett <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="l8rL09h_AwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">ubern...@...> 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 databases.

Of course this is a moot point when sessions are stored in the database, but I won’t start a debate about why Django still encourages this, this isn’t the point of this thread ;-)

For example Redis is well known for advertising that it has no security and should only be run within a secure network. (Defense in depth, anyone?) Still a bunch of companies provide Redis as a service, usually on random EC2 instances directly reachable from the Internet. The best ones require going through an SSL endpoint and providing a password, but an attacker can still talk directly to Redis, which is concerning given its stance on security.

In contrast, the authors of PostgreSQL have implemented an authentication and authorization framework. I’m not qualified to say if it’s robust, but at least it’s better than shrugging off security entirely.

--
Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d7471896-c17e-4c7f-b6eb-757f223229d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...