Importanza di un breve termine di scadenza su JWT

Question

Importanza di un breve termine di scadenza su JWT

#1 da (1 voti)
#2 da (1 voti)

2

Al momento utilizziamo token Web JSON per l'autenticazione per l'API del nostro sito Web. Utilizziamo token di accesso di durata breve di 1 ora che vengono aggiornati mediante un token di aggiornamento revocabile permanente.
Ora vogliamo aggiungere un account + sistema di accesso al sito Web e legarlo all'utilizzo dell'API. Tuttavia, stiamo attualmente discutendo sulla sicurezza di questo.

L'implementazione ingenua sarebbe solo un token di accesso di 3 ore per una sessione e qualcosa come 2 settimane di scadenza se l'utente sceglie l'opzione "resta connesso". Tuttavia, questo renderebbe il breve periodo di scadenza inutile. Nel caso in cui i token vengano trapelati hai una finestra di attacco di due intere settimane.
L'alternativa che pensavamo sarebbe stata una sorta di "proxy" che verifica se il token è scaduto e si aggiorna automaticamente con il token di aggiornamento in localstorage o come cookie.

La versione ingenua sarebbe un'implementazione accettabile o i rischi per la sicurezza sono troppo alti?

authentication jwt web-application account-security

posta nn3112337 18.02.2018 - 21:24

fonte

2 risposte

Leggi altre domande sui tag authentication jwt web-application account-security

Compatibilità hardware con Hashcat in Windows 10 (64-bit) catena di certificati ".DER" è uguale al certificato intermedio. È corretto?

score 1 · Answer 1

Dipende dai requisiti dell'host e della rete in cui ti trovi.

Come con qualsiasi password, un JWT / cookie o qualsiasi altra cosa possa essere, più a lungo l'oggetto è disponibile senza modifiche, più tempo ha un hacker per essere rotto.

Personalmente ho il mio JWT segreto generato con una chiave casuale all'avvio dell'applicazione web.

Ho impostato una durata delle JWT non superiore a 5 ore. Puoi anche cercare altri elementi nel cookie come OS, browser, indirizzo IP ecc. Dipende da come vuoi gestirlo.

Puoi anche far uccidere tutti i JWT alla fine dell'ufficio.

3 hour access token for a session and something like 2 weeks expire time if the user chooses the "stay logged in" option.However, this would kinda make the short expire time useless.

Sono d'accordo. Incoraggiare gli utenti a utilizzare lastpass o keypass potrebbe essere un'opzione. Personalmente ritengo che effettuare il login una volta ogni 5 ore non sia un inconveniente ed è un costo economico per fare affari.

Fammi sapere se questo risponde alla tua domanda o ai tuoi aiuti.

score 1 · Answer 2

Ho avuto preoccupazioni simili quando guardavo al passaggio dalle sessioni stateful all'autenticazione basata su token.

Volevamo uno scenario simile all'attuale validità di "20 minuti dall'ultima richiesta", quindi abbiamo optato per quanto segue:

Al login, generiamo un token valido per 20 minuti e lo inviamo all'utente. Per le richieste successive, convalidiamo quel token e se sono trascorsi più di 5 minuti da quando è stato creato, andiamo avanti e creiamo un nuovo token di 20 minuti e lo inviamo all'utente.

Questi token hanno crittografato 2 segreti casuali: uno per l'applicazione e uno per l'utente (memorizzato nel database accanto al record dell'utente). L'applicazione 1 è stata verificata ad ogni richiesta e l'utente uno è stato controllato ogni volta che un token era previsto per il rinnovo (quindi al massimo ogni 5 minuti).

Se l'utente avesse qualche preoccupazione, poteva o disconnettere tutte le sessioni o cambiare la sua password. Entrambe queste azioni genererebbero un nuovo segreto utente, il che significa che al massimo un vecchio token sarebbe valido solo per 5 minuti. Se ci fosse un problema serio, potremmo cambiare l'applicazione segreta e invalidare immediatamente tutti i token esistenti.