Years later, sorry. But this is still broken and SECRET_KEY management is a mess!
Even though you can now use bytes, this line here will blow up if you attempt to use bytes as a secret key: https://github.com/django/django/blob/3.2.14/django/core/checks/security/base.py#L202 Basically, we are unable to use bytes in the secret key (and we want bytes so we can use a short string for other HMAC/signing operations). This means that our "str" keys will be twice as big (if encoded as hex) and will also always end up hashed because a 64 bytes secret will be a 128 string hex, which is over HMAC-SHA256 block size. El Wednesday, December 28, 2016 a la(s) 6:45:50 AM UTC-3, Aymeric Augustin escribió: > I’m happy with that. > > -- > Aymeric. > > On 27 Dec 2016, at 19:49, Tim Graham <timog...@gmail.com> wrote: > > Thanks Aymeric. How about this documentation addition: > > Uses of the key shouldn't assume that it's text or bytes. Every use should > go > through :func:`~django.utils.encoding.force_text` or > :func:`~django.utils.encoding.force_bytes` to convert it to the desired > type. > > https://github.com/django/django/pull/7750 > > Adam created https://code.djangoproject.com/ticket/27635 about the "use > secrets" idea. > > On Saturday, December 24, 2016 at 4:52:38 PM UTC-5, Aymeric Augustin wrote: >> >> Hello Andres, >> >> We both seem to agree with the status quo — supporting both text and >> bytes. >> >> >> On 24 Dec 2016, at 00:36, 'Andres Mejia' via Django developers >> (Contributions to Django itself) <django-d...@googlegroups.com> wrote: >> >> On 12/22/2016 05:15 PM, Aymeric Augustin wrote: >> >> export SECRET_KEY=… # generated with pwgen -s 50 >> >> What do you think is ultimately being used in the pwgen program? I'm >> going to guess, at least on POSIX systems, it is /dev/urandom or >> /dev/random, both of which return random bytes. >> >> >> I understand this, but it doesn’t change my argument. I’m saying that the >> format of SECRET_KEY doesn’t matter, as long as it contain enough entropy, >> since it will be injected in hashing algorithms designed to extract the >> entropy. I think we can agree on this. >> >> We have different preferences for that format. You like keeping the >> original raw binary data SECRET_KEY. I find it more convenient to convert >> it to an ASCII-safe format, for example with pwgen. I really think this >> boils down to taste. I don’t think we can conclusively determine that one >> approach is superior to the other. I think my technique is more beginner >> friendly; while not applicable to you, it’s a concern for Django in general. >> >> The only cost of supporting both options is that every use must go either >> through force_text or force_bytes to convert to a known type. >> >> - “I think it's fair to assume devs using the SECRET_KEY know it must be >> used as bytes.” — well that doesn't include me or any Django dev I ever >> talked to about this topic >> >> (..) >> >> >> Oops, I misunderstood “used as bytes” to mean “defined as bytes”. Sorry. >> I withdraw this. >> >> >> And since I’ve been waving my hands about the types Django expects in a >> previous email, here’s the full audit. Below, *text* means unicode on >> Python 2 and str on Python 3. *ASCII-safe bytes* means bytes containing >> only ASCII-characters, so they can be used transparently as if they were >> text on Python 2, because it will call decode() implicitly. >> >> - django/conf/global_settings.py >> >> Sets the default to an empty *text* string (note the unicode_literals >> import at the top for Python 2). >> >> - django/conf/settings.py-tpl >> >> Sets the generated value to *ASCII-safe bytes* on Python 2 and *text* on >> Python 3 (no unicode_literals there). >> >> - django/core/signing.py: >> >> Calls force_bytes to support *bytes* and *text* in get_cookie_signer. >> >> - django/utils/crypto.py: >> >> Calls force_bytes to support *bytes* and *text* in salted_hmac. >> >> *Assumes SECRET_KEY contains text* in the `if not using_sysrandom` >> branch of `get_random_string`. This is the bug I hinted to in a previous >> email. It must have appeared when adding the unicode_literals import to >> that file. No one complained since June 2012. It only affects people >> setting their SECRET_KEY to bytes on Python 3 or ASCII-unsafe bytes on >> Python 2 on Unix-like systems that don’t provide /dev/urandom. This sounds >> uncommon. >> >> While we’re there, we should use >> https://docs.python.org/3/library/secrets.html#module-secrets on Python >> >= 3.6. >> >> >> Best regards, >> >> -- >> 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 django-develop...@googlegroups.com. > To post to this group, send email to django-d...@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/50b9dde6-4bab-4f00-b739-df06e90cce3f%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/50b9dde6-4bab-4f00-b739-df06e90cce3f%40googlegroups.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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c2b54e9d-e365-4148-8e5e-fa5c43fea025n%40googlegroups.com.
