È sufficiente memorizzare un ID utente in JWT per verificare l'identità?

1

Ho pensato di provare JWT come alternativa all'autenticazione basata sulla vecchia sessione per motivi di prestazioni (ovvero nessuna ricerca SQL aggiuntiva per l'ID di sessione nel database solo per ottenere l'id utente per ogni richiesta HTTP) e motivi di usabilità (JWT verrà utilizzato nelle intestazioni HTTP invece dei cookie in modo che la mia app possa essere utilizzata come API RESTFUL e accessibile ai client non-browser come le app mobili, inoltre l'aggiunta di JWT nelle intestazioni HTTP elimina il pericolo di CSRF). Poiché il carico utile è firmato con un HMAC sicuro come SHA256, è quasi impossibile falsificare il carico utile. Inoltre, l'ID utente itslef non è realmente un segreto ed è usato pubblicamente dall'app.

Sto pensando di utilizzare un carico utile simile a questo:

{
  id: "1234abcd",
  iat: 1522779638
}

dove iat è un timestamp unix in cui è stato creato il JWT e questo può essere usato per far scadere il messaggio JWT e anche rafforzare la sicurezza randomizzando l'hash per lo stesso id.

La mia domanda è, supponendo che applicherò una connessione HTTPS rigorosa per la mia app in produzione, utilizzando questo payload non crittografato abbastanza sicuro per verificare l'identità dell'utente e avviare metodi non sicuri come i metodi POST (ad esempio, seguire un utente, smettere di seguire un utente , ecc ...) che è sicuro quanto l'autenticazione basata sulla sessione? Devo crittografare il carico utile usando qualcosa come AES-192 o AES-256 solo per essere più sicuro?

    
posta pls no 06.05.2018 - 18:30
fonte

1 risposta

1

Questo sembra sufficiente per autenticare l'utente e proteggere il token in transito. Tuttavia, il problema potrebbe essere che con questo sistema non avresti un buon modo per revocare un tale token. Quindi se il token viene rubato, può essere usato per sempre. Si consiglia di avere un modo per l'utente di revocare questi token. Ci sono molti scenari in cui il token potrebbe essere rubato, dal malware attraverso il telefono rubato al login su PC insicuro diciamo in un internet cafè.

Una possibilità sarebbe semplicemente quella di aggiungere una singola colonna "not-before" alla tabella degli utenti e rifiutare i token con iat inferiore di quello. Quindi l'utente può revocare tutti i token precedentemente emessi impostando questa colonna sul timestamp corrente. Ciò richiederebbe l'accesso al database, ma solo alla tabella degli utenti utilizzando l'ID che probabilmente vorrai comunque fare.

    
risposta data 06.05.2018 - 18:34
fonte

Leggi altre domande sui tag