Gestione corretta della chiave segreta

3

In questo momento, sto pensando che per tutte le richieste in arrivo, il mio server controllerà il token della richiesta contro il token costruito dalla chiave segreta globale della mia app per l'autenticità. L'unico modo per chiunque di hackerare è ottenere il controllo del mio server. poi di nuovo, se qualcuno è riuscito a prendere il controllo del tuo server, sei brindisi, è tutto finito, non è possibile prendere alcuna misura per fermare l'aggressore. c'è qualche difetto in questo argomento?

    
posta user95719 31.12.2015 - 03:42
fonte

1 risposta

2

In realtà, ci sono alcuni modi con cui puoi rendere più difficile un attacco o limitare l'impatto di una breccia qui.

Uno sta usando i segreti per utente e li memorizza separatamente. Il server li vedrebbe solo in memoria e potrebbe essere utilizzata una qualche forma di condivisione del server da parte dell'utente per limitare il numero di segreti per utente esposti a un singolo server compromesso.

Un altro utilizza un sistema KMS separato che genera o convalida token. Questo sistema dovrebbe essere indurito, ma un utente malintenzionato dovrebbe quindi violare più livelli del sistema per rubare i segreti. In alcuni sistemi KMS le chiavi sono memorizzate nel TPM in modo che persino un compromesso morbido del KMS non danneggi le chiavi. Dovrebbero rubare l'hardware stesso in modo che gli attacchi offline dei token siano progettati in modo efficace.

Ricorda che il sistema token potrebbe non essere il link più debole qui. È bello isolarlo per rafforzarlo, ma per avere una sicurezza globale efficace è necessario fare scelte di difesa basate su un modello di minaccia del sistema in cui questo componente è distribuito.

    
risposta data 02.01.2016 - 16:14
fonte

Leggi altre domande sui tag