Potrebbe funzionare questo tipo di sistema JWT?

1

Sto studiando i token Web JSON e voglio provare a creare il mio server di autenticazione (non preoccuparti, non verrà eseguito in produzione da nessuna parte). La mia comprensione fino ad ora è questa: crei una stringa JSON che contiene tutti i dati che desideri e crea un hash basato su questi dati usando un segreto, che includi anche nel JWT. Il segreto è condiviso tra il server di autenticazione e il server delle applicazioni. Il server delle applicazioni che invii le tue richieste utilizza lo stesso segreto per ricalcolare l'hash e confrontarlo con quello nel JWT.

Ora, se per qualche ragione il tuo server delle applicazioni viene compromesso e il segreto viene fuori, sei sfortunato. E potresti non volere che i tuoi utenti analizzino i tuoi JWT. Quindi mi è venuta in mente questa idea:

Avere il server di autenticazione crittografare il JWT con una chiave privata, e quindi avere il server dell'applicazione decrittografarlo con la chiave pubblica significa due cose: i client non possono ispezionare il contenuto dei propri JWT e un comprimato server delle applicazioni significa che si sta ancora non è possibile creare JWT falsi, in quanto la chiave privata non è ancora compromessa. Decodificare con la chiave pubblica significa anche sapere che il JWT proviene dal server di autenticazione. Per quanto posso dire, la crittografia con la chiave privata e la decrittografia con quella pubblica, anche se inusuale, non dovrebbero portare a una crittografia più debole.

La mia domanda: c'è qualcosa di sbagliato nel mio modo di pensare, che potrebbe portare a questo tipo di sistema di autenticazione non funzionante o facile da compromettere?

    
posta ohyeah 27.01.2017 - 19:21
fonte

2 risposte

1

Quello che descrivi qui è poco più di un ID di sessione generato casualmente, tuttavia la maggior parte delle cose che lo differenziano da un ID di sessione sono uno svantaggio per la tua sicurezza. L'unico vantaggio è che si sta memorizzando lo stato sul client e quindi si dispone di una soluzione scalabile e tollerante ai guasti. Ma richiede piuttosto molta elaborazione per decifrare un cifrario asimmetrico.

Tuttavia, poiché il token contiene dati crittografati, ci si affida all'efficacia dell'algoritmo e alla sua implementazione. Gli utenti saranno in possesso sia del testo cifrato che di una parte del testo in chiaro, il che è di grande aiuto per rompere la crittografia.

Come descritto, non c'è nulla da proteggere contro un mitm (ad esempio l'impostazione di un meccanismo di rinegoziazione di ttl e chiave) o di un attacco xss.

Allo stato attuale devi essere molto attento con la disposizione del segreto - ad es. in backup, dischi guasti, immagini san ecc. Confrontalo con un ID di sessione casuale che scade con la sessione.

Sicuramente suddividere la coppia di chiavi (non sembra che sia necessario che una parte sia considerata "pubblica") aggiunge qualche valore, in particolare se il server di autenticazione sta eseguendo un diverso stack software e non è esposto su Internet.

Ma personalmente preferirei un server SSO usando protocolli consolidati (ad esempio openam) e un ID di sessione casuale, eventualmente integrato da token monouso nella memoria locale per la sicurezza del foglio di alluminio.

    
risposta data 29.03.2017 - 00:55
fonte
0

Normalmente non mi piace dire "sì, questo è sicuro", ma arriverò a dire che mi sembra teoricamente sicuro, basato su le informazioni fornite. Tuttavia ...

A parte cose ovvie come il limite alla quantità di dati che un token può contenere (presupponendo RSA) e il fatto che tutti i token sarebbero ~ 256 byte o più grandi (ci sono molti dati da inviare in ogni singola richiesta), Non penso che il tuo sistema sarebbe di aiuto se il tuo server delle applicazioni fosse compromesso, cosa che penso fosse l'idea originale?

In primo luogo, il server compromesso potrebbe semplicemente continuare a richiedere il numero di token che gli piace dal server di autenticazione. Per non parlare del fatto che non sarebbe necessario perché è quello che verifica comunque i token. Potrebbe semplicemente essere riprogrammato per accettare qualsiasi token o nessun token.

In teoria, il tuo sistema ha senso e sembra sicuro per me , il che non significa molto. Ma un server compromesso è un server compromesso alla fine della giornata!

    
risposta data 27.01.2017 - 21:29
fonte

Leggi altre domande sui tag