Nascondere HMAC-SHA256 nel codice sorgente e nel file di configurazione

Question

Nascondere HMAC-SHA256 nel codice sorgente e nel file di configurazione

#1 da (2 voti)

0

Avrebbe senso o fornire un vantaggio di sorta per rompere una chiave segreta HMAC-SHA256 in due componenti e nascondere un componente in un file di configurazione lato server applicabile e l'altro componente in (codice sorgente chiuso, lato server) codice compilato?

Vorrei scegliere che entrambe le metà siano abbastanza lunghe da contenere singolarmente entropia sufficiente a garantire che anche se l'altra metà della chiave è compromessa, l'altra metà della chiave rimane troppo lunga / complessa per essere forzata bruta. Ad esempio, ogni metà è di 32 byte crittografici-sudo-casuali che sono concatenati per formare la chiave segreta completa.

Capisco generalmente che non è consigliabile nascondere le chiavi segrete nel codice sorgente in quanto il codice sorgente è difficile da mantenere segreto, ma non riesco a vedere nulla, ma i vantaggi utilizzando questo. Se la chiave del codice sorgente viene rubata, la chiave di configurazione rimane nascosta e troppo lunga per essere forzata bruta. In alternativa, se un utente malintenzionato riesce a sottrarre la chiave di configurazione ma non conserva una copia della chiave del codice sorgente compilato, non riesce a falsificare le firme dei token JWT.

Quindi la mia domanda è: sto guardando oltre una sorta di difetto evidente in questo progetto o fornisce veramente almeno un po 'di sicurezza migliore? Inoltre, se non ci sono evidenti difetti, è ragionevole credere che ciò contribuisca davvero alla protezione della chiave segreta?

jwt key-management

posta dFrancisco 09.02.2018 - 20:26

fonte

1 risposta

Leggi altre domande sui tag jwt key-management

Che tipo di crittografia viene generalmente utilizzata per le chiavi API? Come posso sbloccare l'unità senza la password o la chiave di ripristino di Bitlocker? [duplicare]

score 2 · Accepted Answer

In base alla descrizione, in pratica dividi il segreto in più parti e le posizioni in posizioni diverse. E queste parti sono abbastanza complesse in modo che un attaccante debba trovare tutti i pezzi per avere successo, cioè non è possibile trovare solo alcune parti e quindi indovinare il segreto rimanente.

Se in questo scenario almeno una di queste posizioni è protetta con la stessa forza di quella che tradizionalmente proteggerebbe il segreto completo, questo sistema split-secret non è meno sicuro rispetto al tradizionale sistema full-secret e potrebbe anche essere più sicuro. Se invece pensi che solo suddividendo le chiavi il sistema diventa più sicuro e si preoccupi meno di proteggere ogni pezzo di quanto tu non abbia a cuore il segreto, allora il sistema a chiave divisa potrebbe essere meno sicuro.

Dalla tua descrizione è impossibile sapere quanto siano protette le parti dei segreti. Il codice sorgente potrebbe essere rubato a seconda di quanto sia protetto o il codice potrebbe essere decodificato a seconda di quanto sforzo è stato fatto per nascondere il segreto nel codice. Simile un file di configurazione potrebbe essere facilmente accessibile o meno. Inoltre, non si sa quanto sia critico il segreto in realtà e quanta protezione ha bisogno. Ad esempio, in alcuni casi d'uso ha più senso cambiare il segreto spesso che investire troppo sforzo nella protezione a lungo termine del segreto. E un segreto che dipende in parte dal codice sorgente potrebbe essere meno flessibile in questi casi.