Token del token del JSON Web Token (JWT) compromesso

Per rispondere alle tue domande:

1) How do you handle a situation with a compromised token secret which is shared between a client and the server?

Aggiungi una data di scadenza al tuo token. Assicurati che il token non possa essere utilizzato dopo la scadenza. Ma questo non impedisce l'accesso non autorizzato all'interno del periodo di scadenza del token.

Quindi, per ovviare a questo problema è possibile incorporare l'indirizzo IP del client o altre informazioni simili all'interno del token. E assicurati che la richiesta in entrata con il token sia utilizzata dallo stesso indirizzo IP a cui è stata inviata.

2) Do you logout all your clients and define a new token secret for future requests? (that would be a bad experience)

Se si intende disconnettere tutti i client che utilizzano più token in modo autorizzato, quindi No. È possibile continuare a utilizzare più token contemporaneamente, a condizione che si disponga di un periodo di scadenza limitato per i token. Questo assicura che i token siano utilizzati entro la finestra temporale prevista.

Ma, se intendi quando il token viene rubato e in qualche modo lo hai capito. È meglio invalidare tutti i token per quell'utente.

Tuttavia, potresti avere un meccanismo che revocherà esplicitamente tutti i token in casi speciali. Può essere come quando l'utente reimposta la sua password perché pensa che la sua password potrebbe essere compromessa.

3) Is there a way to just logout the compromised client?

Può essere, dipende dalla tua capacità di identificare con precisione quale token è stato compromesso. Il che potrebbe portare a tutti i client che utilizzano quel token per perdere l'accesso. Ma non lo raccomanderei. Ma, puoi sempre scrivere codice che si riattiverà dinamicamente e ottenere un nuovo token di accesso quando il vecchio client non può più utilizzare il token. : -)

Non aver paura di invalidare un token quando necessario. Se perdi un token, scrivi uno script dinamico per eseguire nuovamente l'autenticazione. Se ritieni di perdere i dettagli della sessione quando utilizzi un nuovo token, invia nuovamente il token scaduto al server durante la nuova autenticazione. Usando questo token scaduto puoi ricostruire un nuovo token con i dettagli della sessione del vecchio token. A condizione che tu abbia incorporato i dettagli della sessione nel token scaduto.

Se vuoi essere in grado di revocare i token precedentemente concessi prima della loro data di scadenza (un problema di sicurezza valido), dovrai includere una ricerca nel database, il che nega uno dei principali vantaggi di JWT, quindi potresti decidi di non usarli in primo luogo.

Ecco un articolo che parla di questo caso: link

Nel mio caso sto memorizzando anche i token nel mio database.

Durante l'autenticazione iniziale, l'utente invia la password del nome utente. Le credenziali vengono verificate e quindi viene generato un token che viene archiviato nel database e che invia anche il token al client. Su ogni richiesta del cliente, verificherò se il token esiste anche per quell'utente nel mio database.

Se il client si disconnette e desidera revocare il token, rimuovo semplicemente il token dalla tabella delle identità.

I token JWT possono essere decodificati e tutte le informazioni possono essere lette come in formato json, ad esempio:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

La prima parte è intestazione: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

{
  "alg": "HS256",
  "typ": "JWT"
}

La seconda parte è Payload: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

L'ultima parte è la firma creata come:

//In our example, the algorithm is (HS256)
signature = algorithm(hash of (header + payload), secret)

Ora, è la chiave che si nasconde solo all'interno della firma del token, quindi, arriviamo alla conclusione che:

1. La KEY deve essere conservata in un luogo sicuro e non deve essere rivelata a nessuno.
2. IF Token JWT utilizzato per l'autenticazione, deve essere utilizzato su SSL / TLS.
3. Il token JWT non può essere considerato attendibile senza la convalida di signature con la chiave segreta.
4. Il token ISSUER di JWT non deve inserire informazioni sensibili all'interno del token JWT nel caso in cui solo la firma delle informazioni utilizzate con JWT.

akajas

1) How do you handle a situation with a compromised token secret which is shared between a client and the server?

usa SSL / TLS (connessione sicura) e espira ogni token in base al tuo sistema di accesso. Il token JWT deve essere utilizzato come permanente, ogni volta che l'utente effettua l'accesso crea un token JWT.

2) Do you logout all your clients and define a new token secret for future requests? (that would be a bad experience)

SE la tua chiave segreta è compromessa, devi assolutamente creare una nuova chiave segreta e rinnovare le sessioni attive emettendo il log-out e forzare il sistema a riabilitare tutti gli utenti attivi.