Cosa succede se JWT viene rubato?

Question

Sto cercando di implementare l'autenticazione stateless con JWT per le mie API RESTful.

AFAIK, JWT è fondamentalmente una stringa crittografata trasmessa come intestazioni HTTP durante una chiamata REST.

Ma cosa succede se c'è un intercettatore che vede la richiesta e ruba il token? Quindi sarà in grado di falsificare la richiesta con la mia identità?

In realtà, questo problema si applica a tutte le autenticazioni basate su token .

Come impedirlo? Un canale sicuro come HTTPS?

Answer 1

Sono l'autore di una libreria di nodi che gestisce l'autenticazione in modo abbastanza approfondito, express-stormpath, quindi inserirò qui alcune informazioni.

Prima di tutto, le JWT sono in genere NON crittografate. Mentre esiste un modo per crittografare i JWT (vedi: JWEs), questo non è molto comune nella pratica per molte ragioni.

Successivamente, qualsiasi forma di autenticazione (utilizzando JWT o meno), è soggetta agli attacchi di MitM (man-in-the-middle). Questi attacchi si verificano quando un utente malintenzionato può VISUALIZZARE IL TUO traffico di RETE mentre esegui richieste su Internet. Questo è ciò che può vedere il tuo ISP, l'NSA, ecc.

Questo è ciò che impedisce SSL: crittografando il traffico di RETE dal tuo computer -> alcuni server durante l'autenticazione, una terza parte che sta monitorando il tuo traffico di rete può NON vedere i token, le password o qualcosa del genere a meno che non siano in qualche modo in grado di ottenere una copia della chiave SSL privata del server (improbabile). Questo è il motivo per cui SSL è OBBLIGATORIO per tutte le forme di autenticazione.

Diciamo, però, che qualcuno è in grado di sfruttare il vostro SSL ed è in grado di visualizzare il token: la risposta alla tua domanda è che SI, l'attaccante sarà essere in grado di utilizzare tale token per impersonare voi e fare richieste al tuo server.

Ora, questo è dove i protocolli vengono poll.

JWTs sono solo uno standard per un token di autenticazione. Possono essere usati praticamente per qualsiasi cosa. La ragione per cui i JWT sono piuttosto interessanti è che puoi incorporare informazioni extra in loro, e puoi convalidare che nessuno li ha incasinati (firma).

TUTTAVIA, gli stessi JWT non hanno nulla a che fare con la "sicurezza". Per tutti gli intenti e le finalità, le JWT sono più o meno le stesse delle chiavi API: solo stringhe casuali che usi per autenticare da qualche server.

Ciò che rende la tua domanda più interessante è il protocollo utilizzato (molto probabilmente OAuth2).

Il modo in cui OAuth2 funziona è che è stato progettato per fornire ai client token TEMPORANEI (come i JWT!

L'idea è che se il tuo token viene rubato, l'attaccante può usarlo solo per un breve periodo di tempo.

Con OAuth2, è necessario autenticarsi di nuovo con il server ogni tanto, fornendo il proprio nome utente/password O credenziali API e quindi ottenere un token in cambio.

Poiché questo processo si verifica di tanto in tanto, i token cambiano di frequente, rendendo più difficile per gli aggressori impersonare costantemente te senza avere grossi problemi.

Speriamo che questo aiuta ^^

Answer 2

So che questa è una vecchia questione, ma credo di poter cadere il mio $ 0.50 qui, probabilmente, qualcuno può migliorare o fornire un argomento di rifiutare totalmente il mio approccio. Sto utilizzando JWT in un'API RESTful su HTTPS (ofc).

Per far funzionare tutto questo, si dovrebbe sempre emettere i token di breve durata (dipende dalla maggior parte dei casi, nella mia app In realtà sto impostando i exp pretesa a 30 minuti, e ttl a 3 giorni, in modo da poter aggiornare questo token finché la sua ttl è ancora valido e il token non è stato lista nera)

per la authentication service, al fine di invalidare i token, mi piace usare uno strato di cache in memoria (Redis nel mio caso) come JWT blacklist/ban-list nella parte anteriore, in base ad alcuni criteri: (So che rompe il RESTful ph ilosophy, ma i documenti memorizzati sono davvero di breve durata, come ho Blacklist per il loro time-to-live rimanente - ttl claim-)

Nota: nella lista nera gettoni non possono essere aggiornate automaticamente

• Se user.password o è stato aggiornato (richiede la conferma della password), il servizio auth restituisce un token aggiornato e invalida (lista nera) uno o più precedenti, quindi se il client rileva che l'identità dell'utente è stata compromessa in qualche modo, è possibile chiedere all'utente di cambiare la sua password Se non si desidera utilizzare la lista nera per questo, è possibile (ma non vi incoraggio a) convalidare il reclamo iat (emesso a) contro il campo user.updated_at (se jwt.iat < user.updated_at quindi JWT non è valido).
• Utente disconnesso deliberatamente.

Infine convalida il token normalmente come fanno tutti.

Nota 2: invece di utilizzare il token stesso (che è davvero lunga), come chiave della cache, ti suggerisco di generazione e l'utilizzo di un token UUID per il jti reclamo. Il che è buono e penso (non è sicuro dal momento che mi è venuto in mente) è possibile utilizzare lo stesso UUID del token CSRF, restituendo un cookie secure/non-http-only e implementando correttamente l'intestazione X-XSRF-TOKEN utilizzando js. In questo modo si evita il lavoro di calcolo della creazione di un altro token per i controlli CSRF.