Cosa succede se JWT viene rubato?

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

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

Ma cosa succede se c'è un intercettatore che vede la richiesta e ruba il token ? Quindi potrà fingere una richiesta con la mia identità?

In realtà, questa preoccupazione si applica a tutta l' autenticazione basata su token .

Come prevenirlo? Un canale sicuro come HTTPS?

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

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

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

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

Diciamo, tuttavia, che qualcuno è in grado di sfruttare il tuo SSL ed è in grado di visualizzare il tuo token: la risposta alla tua domanda è che SÌ , l'aggressore sarà in grado di utilizzare quel token per impersonare te e fare richieste al tuo server.

Ora è qui che entrano in vigore i protocolli.

I JWT sono solo uno standard per un token di autenticazione. Possono essere usati praticamente per qualsiasi cosa. Il motivo per cui i JWT sono in qualche modo interessanti è che puoi incorporare informazioni extra in essi e puoi confermare che nessuno ha incasinato (firma).

TUTTAVIA, i JWT stessi non hanno nulla a che fare con la "sicurezza". A tutti gli effetti, i JWT sono più o meno la stessa cosa delle chiavi API: solo stringhe casuali che usi per autenticarti su qualche server da qualche parte.

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!) Per l'autenticazione SOLO PER UN BREVE PERIODO DI TEMPO!

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

Con OAuth2, devi autenticarti di nuovo con il server ogni tanto fornendo il tuo nome utente / password o le credenziali API e quindi ottenere un token in cambio.

Poiché questo processo si verifica di tanto in tanto, i token cambieranno frequentemente, rendendo più difficile per gli aggressori impersonare costantemente senza affrontare grossi problemi.

Speriamo che questo aiuti ^^

So che questa è una vecchia domanda, ma penso di poter perdere i miei $ 0,50 qui, probabilmente qualcuno può migliorare o fornire un argomento per rifiutare totalmente il mio approccio. Sto usando JWT in un'API RESTful su HTTPS (ofc).

Affinché ciò funzioni, dovresti sempre emettere token di breve durata (dipende dalla maggior parte dei casi, nella mia app sto impostando il expreclamo su 30 minuti e ttlsu 3 giorni, quindi puoi aggiornare questo token finché ttlè ancora valido e il token non è stato inserito nella blacklist )

Per quanto riguarda authentication service, al fine di invalidare i token, mi piace usare un livello di cache in memoria ( redis nel mio caso) come JWT blacklist/ ban-listin primo piano, a seconda di alcuni criteri: (So che rompe la filosofia RESTful, ma i documenti memorizzati sono davvero di breve durata, come nella lista nera per il loro tempo di vita ttlrimanente - claim-)

Nota: i token nella lista nera non possono essere aggiornati automaticamente

• Se user.passwordo user.emailè stato aggiornato (richiede la conferma della password), il servizio di autenticazione restituisce un token aggiornato e annulla (la lista nera) i precedenti, quindi se il tuo client rileva che l'identità dell'utente è stata in qualche modo compromessa, puoi chiedere a quell'utente di cambiare la sua password . Se non si desidera utilizzare la lista nera per essa, è possibile (ma non vi incoraggio a) convalidare il iatreclamo (emesso presso) rispetto al user.updated_atcampo (se jwt.iat < user.updated_atquindi JWT non è valido).
• Utente disconnesso deliberatamente.

Alla fine convalidi il token normalmente come fanno tutti.

Nota 2: anziché utilizzare il token stesso (che è davvero lungo) come chiave della cache, suggerisco di generare e utilizzare un token UUID per il jtireclamo. Il che è buono e penso (non sono sicuro da quando mi è appena venuto in mente) che puoi usare lo stesso UUID anche del token CSRF, restituendo un secure/ non-http-onlycookie con esso e implementando correttamente l' X-XSRF-TOKENintestazione usando js. In questo modo si evita il lavoro di elaborazione della creazione di un altro token per i controlli CSRF.

Mi dispiace essere un po 'in ritardo su questo, ma avevo le stesse preoccupazioni e ora voglio contribuire con qualcosa sullo stesso.

1) rdegges ha aggiunto un punto eccellente, che JWT non ha nulla a che fare con la "sicurezza" e semplicemente convalida, se qualcuno ha incasinato il payload o meno (firma); ssl aiuta a prevenire le violazioni.

2) Ora, se ssl è anche in qualche modo compromesso, qualsiasi intercettatore può rubare il nostro token al portatore (JWT) e impersonare l'utente reale, un passo di livello successivo che cosa si può fare è cercare la "prova di possesso" di JWT dal cliente .

3) Ora, con questo approccio, il presentatore del JWT possiede una particolare chiave Proof-Of-Possession (POP), che il destinatario può confermare crittograficamente se la richiesta proviene dallo stesso utente autentico o meno.

Ho fatto riferimento a questo articolo Proof of Possesion e sono convinto con l'apporach.

Sarò felice, se in grado di contribuire con qualsiasi cosa.

Saluti (y)

Non possiamo semplicemente aggiungere l'ip dell'host iniziale che ha richiesto di generare questo token JWT come parte del reclamo? Ora quando il JWT viene rubato e utilizzato da una macchina diversa, quando il server convalida questo token, potremmo verificare se l'ip della macchina richiesta corrisponde a quello impostato come parte del reclamo. Ciò non corrisponderebbe e quindi il token può essere rifiutato. Inoltre, se l'utente tenta di manipolare il token impostando il proprio ip sul token, il token verrà rifiutato quando il token viene modificato.