Quali scenari traggono davvero beneficio dai JWT firmati?

2

UPDATE : ho concluso la mia ricerca su questo problema e pubblicato un lungo post di blog che spiega i miei risultati: The Unspoken Vulnerability of JWTs . Spiego come la grande spinta all'uso dei JWT per l'autenticazione locale stia tralasciando un dettaglio cruciale: che la chiave di firma debba essere protetta. Spiego anche che, a meno che non sia disposto a fare di tutto per proteggere le chiavi, è meglio delegare l'autenticazione tramite Oauth o utilizzare gli ID di sessione tradizionali.

(Questo post ha resistito a una battaglia di voto in alto / basso ed è stato a partire da -2. Ero pagato per valutare i sistemi per la loro sicurezza, quindi per favore cerca di non respingere questa indagine e quanto sopra conclusioni collegate tra loro.)

Vedo blog dopo blog e libro dopo libro tout JSON Web Tokens (JWTs) come mezzo per API altamente scalabili che non devono colpire il database per autorizzare ogni richiesta. So che la conferma di una firma risparmia una ricerca nel database, ma mi sembra anche che questo approccio metta i server a un rischio molto maggiore di sfruttamento.

Considerare lo scenario in cui un utente malintenzionato entra in un server e acquisisce l'accesso in lettura all'intero file system, inclusi eventuali database. Supponi anche che l'intrusione non venga rilevata per un po 'di tempo.

Una soluzione tradizionale archivierà hash di password e hash di ID di sessione, lasciando l'attacker ancora incapace di sfruttare l'applicazione attraverso le sue interfacce. D'altra parte, se il server emette JWT firmate per l'autorizzazione downstream, la chiave di firma deve risiedere in un punto non sottoposto a modifiche. Se l'attaccante lo localizza, l'attaccante può successivamente falsificare i token JWT non scaduti per accedere inosservato ai server downstream. (L'autore dell'attacco può essere rilevato effettuando ricerche per confermare il client, ma ciò vanificherebbe lo scopo di utilizzare le firme JWT per l'autorizzazione scalabile.)

Le violazioni del server si verificano. Generalmente, gli account possono leggere più di quanto possano scrivere, quindi sembra ragionevole presumere che la maggior parte delle violazioni siano di sola lettura. Quando accadono, le aziende sono orgogliose quando possono dichiarare che l'impatto è minimo in virtù della memorizzazione di valori hash piuttosto che di testo normale. Sfortunatamente, con l'autorizzazione basata su JWT, la società dovrebbe dire che sì, fanno le password hash, ma tutti gli account sono stati comunque compromessi. (Le sessioni di solito sono meno di un problema a causa delle loro durate più brevi.)

Capisco che ci siano molti usi legittimi delle chiavi, che ci siano diversi approcci alla protezione delle chiavi e che di solito ci siano serie conseguenze per il furto delle chiavi. Tuttavia, in questo caso la gente propone di sostituire un vecchio meccanismo di autorizzazione con uno più nuovo e meno sicuro. Questo è ciò che non ha senso per me.

Eppure molte persone intelligenti hanno dedicato molto impegno agli standard e alle implementazioni per la firma di JWT. L'esistenza del protocollo di introspezione dei token di Oauth è un'ulteriore prova che i sistemi sicuri non farebbero affidamento solo sul token per l'autorizzazione. Quindi quali sono i reali vantaggi dei JWT firmati? A cosa servono veramente le firme JWT?

Ecco gli usi apparentemente più legittimi di cui sono a conoscenza:

  • La firma con un segreto a livello di server consente di ridurre al minimo l'impatto degli attacchi DoS, poiché le richieste possono essere generalmente interrotte prima di colpire il database.
  • Convalidare i dati del carico utile JWT che richiede solo un livello intermedio di sicurezza. (Ho difficoltà a immaginare questi dati.)
  • Permettere ai microservizi non affidabili di condividere in modo efficiente le informazioni di autorizzazione acquisite da un servizio di autenticazione comunemente utilizzato. Consulta la descrizione alle API nordiche . (Ma sto ancora cercando di apprezzare il vantaggio.)

Ho pensato al primo di questi, anche se è probabile che anche altri lo facciano. Ho difficoltà a capire gli altri usi. Non ho ancora visto una spiegazione chiara e convincente del motivo per cui qualcuno firma i JWT.

Qual è il vero scoop? Grazie per il tuo aiuto!

(Contesto della domanda: sto cercando di decidere se abbandonare l'idea di ottenere scalabilità attraverso l'autorizzazione basata su firma.)

P.S. Ho visto le firme JWT descritte come uno schema alternativo di "autenticazione". Sono piuttosto sicuro che l'autenticazione si verifica durante l'acquisizione di token e successivamente è solo l'autorizzazione. Per favore correggimi se sbaglio.

    
posta Joe Lapp 05.06.2016 - 02:26
fonte

2 risposte

2

Hai già menzionato i benefici federali stateless dei JWT, sono sicuro che quelli possono essere concordati.

Un utente malintenzionato non ha bisogno della password di un utente per accedere alle risorse protette, basta accedere al loro contesto di autenticazione.

Penso che uno dei rischi che ti manchi con i token di sever side, o metodi basati su sessioni, è che quegli identificatori sono anche memorizzati sul server. Di fatto sono spesso archiviati in posti che sono più frequentemente compromessi in sola lettura rispetto al filesystem (dove le chiavi private sono più spesso memorizzate), il database. Una volta che un utente malintenzionato ha un ID sessione o un token di autenticazione, ha la stessa capacità di accedere ai partner di supporto come con un JWT.

Un altro anello debole nella catena è l'archiviazione lato utente, che è spesso un compromesso più facile in un attacco mirato rispetto al server. Questo rischio può essere mitigato piuttosto dai token di ciclismo frequenti; una caratteristica fondamentale dei sistemi JWT ben implementati, ma non frequentemente con i token di sessione di lunga durata in pratica.

    
risposta data 05.06.2016 - 07:51
fonte
0

C'è una bella recensione su JWT usati per gestione delle sessioni di Sven Slootweg. Verso la fine dell'articolo si menzionano anche alcuni casi d'uso in cui si può beneficiare di JWT.

In particolare, parla delle esigenze di autorizzazione monouso. L'esempio è un server di download, che accetta JWT per autorizzare l'accesso ai file. Lo stesso server di download può essere mantenuto senza stato poiché il JWT ha tutte le informazioni necessarie per autenticare e autorizzare i client.

    
risposta data 06.08.2017 - 23:02
fonte