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 <timogra...@gmail.com> 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-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/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/CAD9P0JoLaJvOQYAGOzW3wZBNJQowmaWHpo1MfEXiqYbfXzFLOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to