Re: A Django Async Roadmap
Hello Andrew. I like your proposal and want to help out. In particular, what I'm really fond of is the approach of making async available only if you want it, while keeping Django backwards-compatible. Django is brilliant in that, like the Python language, it's easy and fun to pick and learn, but flexible and powerful at the same time. Rigel. On Mon, Jun 4, 2018 at 3:17 PM, Andrew Godwin wrote: > Hello everyone, > > For a while now I have been working on potential plans for making Django > async-capable, and I finally have a plan I am reasonably happy with and > which I think we can actually do. > > This proposed roadmap, in its great length, is here: > > https://www.aeracode.org/2018/06/04/django-async-roadmap/ > > I'd like to invite discussion on this potential plan - including: > > - Do we think async is worth going after? Note that this is just async > HTTP capability, not WebSockets (that would remain in Channels) > > - Can we do this in a reasonable timeframe? If not, is there a way around > that? > > - Are the proposed modifications to how Django runs sensible? > > - How should we fund this? > > There's many more potential questions, and I really would love feedback on > this. I'm personally pretty convinced that we can and should do this, but > this is a decision we cannot take lightly, and I would love to hear what > you have to say. > > Andrew > > -- > 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/CAFwN1up4%2BP%2B4bCSSiG6t845idoM8dvktnuTs4dH > 2R5aAuCz3iA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFwN1up4%2BP%2B4bCSSiG6t845idoM8dvktnuTs4dH2R5aAuCz3iA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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/CAD9P0JrY%3DwdtPsk9-xLhALM_4Y4ZK2uSaT6MEjKt7Nd2-DDjUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 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 : >> > >> > 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.
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 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 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/CAD9P0Jr8uKogoeUz%3Dx1CHpC0hKQ4qyt5DVQo7vx-rZka7pYVyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
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 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 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/CAD9P0Jr-pYSM%3DJkwiWoNg-BbfFbCxYW5ucbPy_dwssbiXS1d3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
