La realtà è se altri processi possono accedere alla memoria del processo o alle funzionalità del tuo
macchina virtuale, il gioco è probabilmente finita perché sei già compromesso. Se un processo
ha accesso a questo livello, può probabilmente ottenere altre informazioni, come l'iniziale
le credenziali utilizzate per l'autenticazione prima di ottenere il token o semplicemente la modifica
risultati per rendere true la verifica del token nonostante il risultato della verifica effettiva
ecc. Non concentrarti troppo sulle possibilità estreme. La maggior parte dei compromessi si verifica attraverso
exploit molto più semplici o errori di configurazione, come la memorizzazione della chiave privata sul
file system che è leggibile in tutto il mondo e accessibile al tuo server web, ecc.
Il modo migliore per gestire chiavi e segreti dipenderà un po 'dalla tua piattaforma. Alcuni
le piattaforme forniscono quadri di gestione delle chiavi e forse l'uso di una di queste sarebbe
. Appropriato
Non concentrarti troppo sul fatto che questa è una chiave segreta. In realtà, non c'è più
critico rispetto ad altre credenziali che devi gestire. Ad esempio, come gestisci
le credenziali che consentono l'accesso ai tuoi database? Se quella soluzione è abbastanza buona
per i tuoi database, probabilmente è abbastanza buono per la tua chiave segreta. Se non lo è,
quindi mi chiederei se è effettivamente abbastanza buono per il tuo database. La realtà
è, se qualcuno sta per compromettere il sistema, allora è probabile che lo stiano facendo
per accedere a qualsiasi dato / servizio che l'interfaccia sta fornendo. Nella maggior parte dei casi,
anche questo servizio o database sottostante ha bisogno di credenziali e gestione delle credenziali
e queste sono le vere chiavi del regno.
Penso che sia meglio usare un approccio coerente per gestire tutte le credenziali del tuo
l'applicazione ha bisogno e non trattare la chiave segreta per la creazione / verifica di token come
molto speciale. Non pensare troppo alla soluzione semplicemente perché implica parole come
'chiave' o 'segreto'. Tutte le credenziali sono dati sensibili che devono essere gestiti in a
modo sicuro. Una buona parte degli errori che vengono fatti sono dovuti a
soluzioni complesse ingegnerizzate che diventano difficili da mantenere e facili da ottenere
sbagliato. Considera soluzioni che utilizzano strutture / strutture esistenti, note e testate,
come keytool , key chain manager ecc. In caso contrario, usa qualcosa che può essere
facilmente compreso e mantenuto Qualcosa di semplice come un database può essere
sufficiente. Evitare soluzioni che implichino la memorizzazione delle informazioni come costanti o
variabili globali in quanto ciò può diventare difficile da mantenere perché si cambia la chiave
ora significa un cambio di codice e ora devi testare, cambiare gestione e promuovere
produzione, ecc.
Riguardo al modo in cui generi le chiavi, beh ciò dipenderà dal tuo ambiente e dal
tipi / livelli di rischi che devi gestire. Come regola generale, sono sempre molto diffidente nei confronti di
tutto ciò che si basa su "random". La generazione di valori casuali veri è estremamente
difficile e spesso non fa nulla per migliorare la sicurezza. In realtà, ipotesi di
la casualità che in seguito si è rivelata non casuale può rivelare schemi, che in
girare significa la possibilità di poter prevedere i valori futuri, che è quasi
sempre una brutta cosa quando parli di chiavi. In questo scenario, non penso
la casualità ti farà guadagnare molto da una prospettiva di sicurezza a meno che tu non sia in una
ambiente in cui è fondamentale che gli amministratori di sistema non conoscano la chiave. Allo stesso modo,
è improbabile che un cambio regolare della chiave offra molto altro che un inconveniente
i tuoi utenti. Ogni volta che cambi la chiave, diventeranno tutti i token attualmente emessi
non valido. Potresti voler prendere in considerazione la possibilità di cambiare la chiave quando lo staff
lasciare o cambiare i ruoli e si potrebbe anche prendere in considerazione una politica per cambiare la chiave ogni volta
il software è aggiornato, ecc
Tuttavia, religiosamente cambiando la chiave ogni settimana o giù di lì
è improbabile che fornisca qualcosa per quanto riguarda la sicurezza.
Si noti che quanto sopra non vale per tutte le chiavi. Ci sono situazioni in cui a
la chiave privata deve essere gestita con estrema cura, ad esempio la chiave privata per
CA principale. Non tutte le chiavi sono uguali. Il tuo approccio gestionale deve corrispondere al
requisiti e rischi che è necessario proteggere contro. Nel caso di JWT, lo sei
occuparsi di un ecosistema in gran parte chiuso - la chiave è usata per generare / firmare e verificare
gettoni. L'obiettivo è il rilevamento della manomissione, non la protezione della segretezza. Il
il rischio è che se qualcuno ottiene la chiave, può creare token e guadagni falsi
accesso non autorizzato al tuo servizio. Ciò che questo significa in definitiva dipende dal
servizio. La misura in cui qualcuno proverà a farlo dipende anche da
servizio sottostante e il suo valore percepito. Le lunghezze a cui vai per fissare la chiave
dovrebbe riflettere la minaccia.