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 <timog...@gmail.com > <javascript:>> 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 <alex....@gmail.com>: > >> > > >> > 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 django-develop...@googlegroups.com <javascript:>. > > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
