Cel ustawienia Django „SECRET_KEY”

157

Jaki dokładnie jest sens SECRET_KEYin django? Przeprowadziłem kilka wyszukiwań w Google i sprawdziłem dokumenty ( https://docs.djangoproject.com/en/dev/ref/settings/#secret-key ), ale szukałem bardziej szczegółowego wyjaśnienia tego, i dlaczego jest to wymagane.

Na przykład, co mogłoby się stać, gdyby klucz został przejęty / inni wiedzieli, co to jest? Dziękuję Ci.

— David542
źródło

Jeśli masz tajny klucz, który został naruszony i udostępniony innym, masz problem. Nie ma znaczenia, czy używasz Django, czy nie.

— Jared Farrish,

Ale jaki dokładnie problem?

— tobych

Zrobiłem gruntowną odpowiedź tutaj (bezwstydny wtyczkę)

— sberder

@sberder Może powinieneś również napisać odpowiedź na to pytanie. Wyobrażam sobie, że mógłbyś to zrobić znacznie lepiej niż zaakceptowana brak odpowiedzi.

— kasperd

Odpowiedzi:

Służy do tworzenia skrótów. Popatrz:

>grep -Inr SECRET_KEY *
conf/global_settings.py:255:SECRET_KEY = ''
conf/project_template/settings.py:61:SECRET_KEY = ''
contrib/auth/tokens.py:54:        hash = sha_constructor(settings.SECRET_KEY + unicode(user.id) +
contrib/comments/forms.py:86:        info = (content_type, object_pk, timestamp, settings.SECRET_KEY)
contrib/formtools/utils.py:15:    order, pickles the result with the SECRET_KEY setting, then takes an md5
contrib/formtools/utils.py:32:    data.append(settings.SECRET_KEY)
contrib/messages/storage/cookie.py:112:        SECRET_KEY, modified to make it unique for the present purpose.
contrib/messages/storage/cookie.py:114:        key = 'django.contrib.messages' + settings.SECRET_KEY
contrib/sessions/backends/base.py:89:        pickled_md5 = md5_constructor(pickled + settings.SECRET_KEY).hexdigest()
contrib/sessions/backends/base.py:95:        if md5_constructor(pickled + settings.SECRET_KEY).hexdigest() != tamper_check:
contrib/sessions/backends/base.py:134:        # Use settings.SECRET_KEY as added salt.
contrib/sessions/backends/base.py:143:                       settings.SECRET_KEY)).hexdigest()
contrib/sessions/models.py:16:        pickled_md5 = md5_constructor(pickled + settings.SECRET_KEY).hexdigest()
contrib/sessions/models.py:59:        if md5_constructor(pickled + settings.SECRET_KEY).hexdigest() != tamper_check:
core/management/commands/startproject.py:32:        # Create a random SECRET_KEY hash, and put it in the main settings.
core/management/commands/startproject.py:37:        settings_contents = re.sub(r"(?<=SECRET_KEY = ')'", secret_key + "'", settings_contents)
middleware/csrf.py:38:                % (randrange(0, _MAX_CSRF_KEY), settings.SECRET_KEY)).hexdigest()
middleware/csrf.py:41:    return md5_constructor(settings.SECRET_KEY + session_id).hexdigest()

— Roshan Mathews
źródło

Dlaczego wtedy nie nazwali tego solą? ;)

— datenwolf

To przypuszczenie, ale przypuszczam, że łatwiej jest powiedzieć ludziom „nie udostępniaj swojego SECRET_KEY”, niż „twój SALTjest tajnym kluczem, który powinieneś zachować dla siebie”.

— Roshan Mathews

To rozróżnienie jest bardzo ważne. W kryptografii sole nie są tajemnicą, ale SECRET_KEYmuszą być bezpieczne. Użycie the SECRET_KEYjest znacznie bardziej zbliżone do użycia klucza w podpisanym skrócie, takim jak HMAC (który, gdyby wydajność nie był brany pod uwagę, prawdopodobnie zostałby użyty zamiast tego).

— Travis Jensen

To nie wygląda na odpowiedź dla mnie. Wszystko, co zrobiłeś, to jedno polecenie grep bez wyjaśnienia, co robi. Gdzie jest odpowiedź na pytanie „co mogłoby się stać, gdyby klucz został przejęty?”?

— kasperd

Ponieważ klucz SECRET_KEY jest poufny, przedrostek SECRET przed kluczem zapewnia, że Django zaszyfruje / zamaskuje wartości, gdziekolwiek będzie to potrzebne.

— Linus_30

Dokumentacja Django dotycząca podpisów kryptograficznych obejmuje zastosowania ustawienia „SECRET_KEY”:

Ta wartość [ SECRET_KEYustawienie] jest kluczem do zabezpieczenia podpisanych danych - ważne jest, aby zachować to bezpieczeństwo, w przeciwnym razie atakujący mogą użyć jej do wygenerowania własnych podpisanych wartości.

(Do tej sekcji odwołuje się również dokumentacja Django dotycząca ustawienia „SECRET_KEY” ).

Interfejs API do podpisywania kryptograficznego w Django jest dostępny dla każdej aplikacji w celu zapewnienia kryptograficznie bezpiecznych podpisów wartości. Samo Django wykorzystuje to w różnych funkcjach wyższego poziomu:

Podpisywanie danych serializowanych (np. Dokumenty JSON).
Unikalne tokeny dla sesji użytkownika, prośby o zresetowanie hasła, wiadomości itp.
Zapobieganie atakom typu cross-site lub replay poprzez dodawanie (a następnie oczekiwanie) unikalnych wartości dla żądania.
Generowanie unikalnej soli do funkcji haszyszu.

Zatem ogólna odpowiedź brzmi: jest wiele rzeczy w aplikacji Django, które wymagają podpisu kryptograficznego, a ustawienie 'SECRET_KEY' jest do nich kluczem. Musi mieć silną kryptograficznie ilość entropii (trudną do odgadnięcia dla komputerów) i unikalną między wszystkimi instancjami Django.

— duży nos
źródło

„i niepowtarzalny między wszystkimi instancjami Django”. - czy to oznacza, że jeśli mówię, że mam 3 serwery internetowe z tą samą aplikacją Django za modułem równoważenia obciążenia, powinienem mieć 3 różne SECRET_KEYustawienia?

— Adam Parkin

@AdamParkin, brzmi to jak dobry początek dla nowego pytania , aby uzyskać własną odpowiedź.

— bignose

Świetna sugestia, gotowe: stackoverflow.com/questions/51657422/…

— Adam Parkin

Zgodnie z dokumentacją Django na tematSECRET_KEY :

Tajny klucz służy do:

Wszystkie sesje, jeśli używasz innego zaplecza sesji niż django.contrib.sessions.backends.cachelub używasz domyślnego get_session_auth_hash().

Wszystkie wiadomości, jeśli używasz CookieStoragelub FallbackStorage.

Wszystkie tokeny PasswordResetView.

Jakiekolwiek użycie podpisu kryptograficznego, chyba że podano inny klucz.

Jeśli obrócisz swój tajny klucz, wszystkie powyższe zostaną unieważnione. Tajne klucze nie są używane do haseł użytkowników i rotacja kluczy nie ma na nie wpływu.

— Michael B.
źródło

Przydatne informacje dotyczące tego, co się stanie, jeśli SECRET_KEYzostanie obrócony. +1

— Hassan Baig