Scopo dell'impostazione di Django "SECRET_KEY"

157

Qual è esattamente il punto di SECRET_KEYin in django? Ho fatto alcune ricerche su Google e verificato i documenti ( https://docs.djangoproject.com/en/dev/ref/settings/#secret-key ), ma stavo cercando una spiegazione più approfondita di questo, e perché è richiesto.

Ad esempio, cosa potrebbe accadere se la chiave fosse compromessa / altri sapessero cosa fosse? Grazie.

— David542
fonte

Se hai una chiave segreta, ed è compromessa e rilasciata ad altri, hai un problema. Non importa se stai usando Django o no.

— Jared Farrish,

Ma quale problema, esattamente?

— incontro il

Ho fatto una risposta completa qui (spina spudorata)

— sberder

@sberder Forse dovresti scrivere anche una risposta a questa domanda. Immagino che potresti farlo molto meglio della non risposta accettata.

— Kasperd,

Risposte:

È usato per fare hash. Guarda:

>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
fonte

Perché non l'hanno chiamato sale allora? ;)

— datenwolf,

Questa è una supposizione, ma suppongo che sia più facile dire alla gente "non condividere il tuo SECRET_KEY", al contrario di "la tua SALTè una chiave segreta che dovresti tenere per te".

— Roshan Mathews,

Questa distinzione è molto importante. Nella crittografia, i sali non sono segreti, ma SECRET_KEYdevono essere tenuti al sicuro. L'uso di the SECRET_KEYè molto più simile all'uso di una chiave in un hash firmato come HMAC (che, se le prestazioni non fossero una considerazione, probabilmente verrebbe usato invece).

— Travis Jensen,

Questa non mi sembra una risposta. Tutto quello che hai fatto è stato un singolo comando grep senza spiegare ciò che fa. Dov'è la risposta a "cosa potrebbe accadere se la chiave fosse compromessa?"?

— Kasperd,

Inoltre, poiché SECRET_KEY è riservato, il prefisso di un SECRET sulla chiave garantisce che Django crittograferà / maschererà i valori dove mai necessario.

— Linus_30,

La documentazione di Django per la firma crittografica copre gli usi dell'impostazione "SECRET_KEY":

Questo valore [l' SECRET_KEYimpostazione] è la chiave per proteggere i dati firmati - è fondamentale tenerlo al sicuro, o gli aggressori potrebbero usarlo per generare i propri valori firmati.

(Questa sezione fa anche riferimento alla documentazione di Django per l'impostazione "SECRET_KEY" .)

L'API di firma crittografica in Django è disponibile per qualsiasi app per firme crittograficamente sicure sui valori. Django stesso si avvale di questo in varie funzionalità di livello superiore:

Firma di dati serializzati (ad es. Documenti JSON).
Token univoci per una sessione utente, richiesta di reimpostazione password, messaggi, ecc.
Prevenzione di attacchi cross-site o replay aggiungendo (e quindi prevedendo) valori univoci per la richiesta.
Generare un sale unico per le funzioni di hash.

Quindi, la risposta generale è: ci sono molte cose in un'app Django che richiedono una firma crittografica e l'impostazione 'SECRET_KEY' è la chiave utilizzata per quelle. Deve avere una quantità di entropia crittograficamente forte (difficile da indovinare per i computer) e unica tra tutte le istanze di Django.

— Nasone
fonte

"e unico tra tutte le istanze di Django." - questo implica che se avessi 3 server web con la stessa app Django dietro un bilanciamento del carico dovrei avere 3 SECRET_KEYimpostazioni distinte ?

— Adam Parkin,

@AdamParkin, sembra un buon inizio per una nuova domanda , per ottenere la propria risposta.

— bignose il

Ottimo consiglio, fatto: stackoverflow.com/questions/51657422/…

— Adam Parkin

Secondo la documentazione di Django suSECRET_KEY :

La chiave segreta viene utilizzata per:

Tutte le sessioni se si utilizza un back-end di sessione diverso da django.contrib.sessions.backends.cacheo si utilizza l'impostazione predefinita get_session_auth_hash().

Tutti i messaggi se si sta utilizzando CookieStorageo FallbackStorage.

Tutti i token PasswordResetView.

Qualsiasi utilizzo della firma crittografica, a meno che non venga fornita una chiave diversa.

Se si ruota la chiave segreta, tutto quanto sopra verrà invalidato. Le chiavi segrete non vengono utilizzate per le password degli utenti e la rotazione delle chiavi non li influenzerà.

— Michele B.
fonte

Informazioni utili su cosa succede se SECRET_KEYviene ruotato. +1

— Hassan Baig,