Il mio piano di aggiornamento JWT è sicuro?

Question

Il mio piano di aggiornamento JWT è sicuro?

#1 da (21 voti)
#2 da (-1 voti)

19

Ho intenzione di utilizzare JWT per il mio sistema di login per dispositivi mobili. Non esiste un vero flusso di lavoro standard per l'aggiornamento dei token JWT che ho trovato, quindi l'ho creato di seguito. Il motivo per cui voglio utilizzare JWT è per motivi di prestazioni. Invece di verificare se un utente è valido con una chiamata al database per ogni singola richiesta, mi fido del JWT.

Ho il flusso di lavoro proposto che voglio implementare nella mia app. Questo è accettabilmente sicuro? Efficiente? Ci sono problemi evidenti che sto supervisionando? Quali miglioramenti ragionevoli possono essere fatti?

Accesso utente

Se non esiste un token con firma HMAC all'interno di localstorage, l'utente assegna un nome al dispositivo.
DeviceName viene inviato al server in cui viene inserito nel database.
Token JWT + token firmato HMAC di DeviceName vengono inviati all'utente. Il token con firma HMAC viene messo in atto per assicurarsi che il token jwt (contenente DeviceName) venga inviato dallo stesso dispositivo che lo ha chiamato in origine.
Il token JWT è valido per X ore, quindi un utente può effettuare chiamate per X ore.
Dopo X ore, il JWT è scaduto. Quando viene effettuata una richiesta, il server può vedere che il JWT è scaduto. Il server ora tenterà di aggiornare il token JWT. Server controlla il database per vedere se il DeviceName specificato nel token firmato HMAC è uguale a un nome di dispositivo valido nel database per quell'utente.
In tal caso, crea un nuovo JWT valido per altre X ore, se no, invia nuovamente il messaggio per richiedere l'accesso.

Se un account è compromesso:

L'utente può accedere al servizio di password. Una volta effettuato l'accesso, recupererei tutti i dispositivi per quell'utente, l'utente può quindi revocare il dispositivo compromesso. Una volta eseguita questa operazione, una richiesta di aggiornamento del JWT non funzionerà con il token rubato.

Ovviamente tutto ciò avviene su SSL.

Le mie preoccupazioni per le quali non ho soluzioni:

Se un token JWT viene rubato, l'hacker ha X ore per effettuare chiamate in base alla vittima. Penso che questa sia la natura dei token e un rischio accettato?
Se il JWT viene rubato, significa che ci sono buone probabilità che il token HMAC contenente il nome del dispositivo sia anch'esso dirottato, in modo che l'utente possa aggiornare i token fino a quando la vittima non si rende conto che il suo account è compromesso e revoca l'accesso. Questa pratica è accettata?

authentication oauth mobile token

posta user2924127 08.06.2015 - 23:31

fonte

2 risposte

-1

La sicurezza è sempre relativa e con più sforzi possiamo rendere più difficile per chiunque abusare del sistema. I token al portatore sono legati all'IO (chiamata cache / database) e i token JWT sono vincolati alla CPU (crittografia / decrittografia). Entrambi sono una soluzione abbastanza buona per il mondo dei servizi regolari, tranne per una cosa che stiamo prendendo in considerazione sui dispositivi mobili qui. Uno degli approcci che potrebbero essere utilizzati qui è quello di inviare il token di aggiornamento / token al dispositivo attraverso il backchannel invece di inviarlo come parte dell'autenticazione. Sembra un po 'più di lavoro, ma offre un po' più di sicurezza in merito all'emissione e all'aggiornamento dei token per i dispositivi mobili. Maggiori dettagli possono essere trovati qui link

risposta data 01.11.2016 - 05:58

fonte

Leggi altre domande sui tag authentication oauth mobile token

Quanto è sicuro il riconoscimento facciale di Android? Biometrico rispetto ad altri meccanismi di autenticazione a due fattori

score 21 · Accepted Answer

Accettabilmente sicuro nel regno di cosa?

Hai descritto il flusso di base per tutti i token bearer. Coloro che portano il segno hanno il potere. Si ha una condizione in cui si controlla se il token è stato revocato, ma ciò significa che il token è valido fino alla scadenza o alla revoca. Questo è fondamentalmente lo stesso che controllare se l'utente è valido nel database, ma stai sostituendo l'utente con dispositivo + JWT. Va bene, ma non è un guadagno in termini di prestazioni.

Gli altri sistemi usano due JWT (o un JWT e un token opaco). Il primo JWT è il token di accesso utilizzato per lo più come descritto, ma non si controlla la revoca. Questo token ha una vita molto breve - forse 20 minuti - > 1h, e poi hai il tuo token di aggiornamento che vive considerevolmente più a lungo. Quando il token di accesso scade, invii il token di aggiornamento e se il token di aggiornamento è ancora valido, emetti un nuovo token di accesso. Se il token di aggiornamento è scaduto, puoi forzare nuovamente l'autenticazione o semplicemente emettere un nuovo token di accesso e aggiornamento.

Il valore qui è che devi solo convalidare il token di aggiornamento sul database e devi farlo solo quando il token di accesso scade. Quando l'utente contrassegna il token di aggiornamento come revocato, il token di aggiornamento non ottiene un nuovo token di accesso.

Il compromesso è che non si esegue una query nel database come spesso, ma l'utente malintenzionato può fare tutto ciò che desidera purché il token di accesso sia valido. Questo è mitigato usando un token molto breve (è un gioco di probabilità). Se questo è un rischio accettato, dipende totalmente da te. Non stabiliamo se è necessario accettare il rischio. :)