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 

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 < 
> <javascript:>>: 
> > 
> > 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 post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to