È sicuro implementare l'autenticazione JWT con i cookie, il controllo delle versioni dei token e nessun token di aggiornamento?

1

Ho alcune domande sulla mia implementazione della sicurezza del token bearer (JWT per essere precisi) in un progetto di asp.net core 2.0 su cui sto lavorando. Il token al portatore viene utilizzato quando l'app web frontend parla con un Api separato (entrambi sono controllati da me e vivono sullo stesso server).

In primo luogo, vorrei riassumere ciò che ho implementato e il mio ragionamento:

I token di accesso vengono archiviati tramite un cookie sicuro solo http

Credo che questo limiti la superficie di attacco a solo XSRF (correggimi se sbaglio). Per prevenire contro XSRF ho implementato token antifora / XSRF.

I token di accesso hanno un numero di versione

La tabella Utenti personali ha una colonna per la versione token e questo numero è incluso quando si rilascia un token di accesso per l'utente.

  • Se le versioni del token non corrispondono durante l'autenticazione / l'autorizzazione, la richiesta viene respinta e viene emessa una richiesta di verifica
  • C'è una logica che aggiorna automaticamente la versione del token quando applicabile (cioè un amministratore blocca un account, l'utente cambia la posta elettronica o si disconnette, ecc) - Può anche essere modificato manualmente se necessario, ad esempio se diventa noto che un account specifico è stato compromesso o qualsiasi altro valido motivo per revocare l'accesso
  • Nota a margine: ho implementato un modo per evitare i costanti riscontri del database quando gli utenti attivi richiedono il controllo del numero di versione e possono elaborare se necessario, ma non penso che si applichi direttamente ai miei problemi di sicurezza in questa domanda

Nessun token di aggiornamento e scadenza per i token di accesso

Non uso affatto token di aggiornamento e i miei token di accesso scadono dopo 7 giorni (a meno che "ricordati di me" sia deselezionato, nel qual caso la scadenza è impostata su Session). Ecco la mia giustificazione:

  • La funzionalità della versione di token risolve il problema di dover revocare un token di accesso mentre la sua scadenza è ancora valida
  • Anche con una scadenza dei token di accesso molto breve, un account / sessione compromesso potrebbe semplicemente utilizzare il token di aggiornamento più a lungo per acquisire un nuovo token di accesso valido, quindi sto tagliando il middle man (correggimi se ho torto o ingenuo)

Quindi, ecco le mie domande specifiche (e per chiarire, non sto chiedendo pareri sulle migliori pratiche e simili, ma per risposte obiettive sull'opportunità o meno che l'implementazione soddisfi un ragionevole livello di sicurezza):

  1. L'uso di un cookie solo http limita la superficie di attacco solo agli attacchi XSRF? E XSRF può essere "completamente" impedito tramite i token Antiforgery / XSRF?
  2. Il sistema di controllo delle versioni di token è un modo valido per garantire la corretta revoca dell'accesso?
  3. È ragionevole rinunciare ai token di aggiornamento e consentire tempi di scadenza dei token di accesso più lunghi quando è in uso un sistema di controllo delle versioni di token (e i token sono protetti tramite cookie http e tattiche antifora)?
posta debuggingmyhead 09.01.2018 - 14:04
fonte

0 risposte

Leggi altre domande sui tag