Assicurarsi che il messaggio firmato non possa essere riutilizzato tramite la chat IRC

Esistono quattro approcci principali a questo tipo di problema, che possono essere combinati per ottenere proprietà di sicurezza più desiderabili.

• Memorizza nella cache i messaggi ricevuti. In questo approccio mantieni una lista (degli hash) di tutti i messaggi ricevuti. Se trovi un messaggio in tale elenco, lo scarti come replay. Il problema ovvio qui è la quantità di spazio di archiviazione necessaria.
• Utilizza timestamp / scadenza. In questo approccio aggiungi ai tuoi messaggi una data / ora o una scadenza. Se vengono ricevuti al di fuori della finestra concordata vengono scartati. Lo svantaggio qui è che se l'attaccante è abbastanza veloce da poter ancora riprodurre e è necessario avere un orologio affidabile. Questo può essere efficacemente combinato con il primo approccio.
• Utilizza i numeri di sequenza. In questo approccio aggiungi un numero di sequenza ai tuoi messaggi. I messaggi vengono scartati se il loro numero di sequenza è inferiore al valore previsto. L'ovvio svantaggio è che è richiesta la sincronizzazione dello stato.
• Utilizza challenge-response. In questo approccio il client invia una sfida imprevedibile al server, il server include questa sfida nel messaggio e il client mantiene la sfida in white list. Non appena viene ricevuta una risposta in sospeso a una sfida aperta, il messaggio viene accettato come valido. Non appena è stata accettata una sfida valida, la sfida non deve più essere considerata valida per un uso futuro (cioè scartata). L'ovvio svantaggio di questo è che le parti devono essere on-line, ossia scambiarsi messaggi in qualche modo simmetrici e in modo tempestivo.

Per il tuo sistema, sembra che la sincronizzazione minima dei primi due approcci offra ciò di cui hai bisogno.
TLS utilizza il terzo approccio per il trasporto di dati di massa e qualcosa come l'ultimo per l'handshake.

Non sono sicuro, ma sto pensando che forse esiste un problema XY in questa domanda.

Questa è la mia ipotesi sul tuo scenario:

1. Il browser dell'utente tenta di accedere a una funzione dell'applicazione limitata
2. L'applicazione invia il browser al sito Web dell'identità per ottenere un token artefatto o portatore contenente l'autorizzazione necessaria per utilizzare la funzione riservata
3. Il sito Web Identity verifica l'identità dell'utente, genera un artefatto che indica che le autorizzazioni sono corrette per l'operazione, lo firma e lo restituisce al browser
4. Il browser accede alla funzione riservata, ma questa volta con il token che indica che l'utente ha le autorizzazioni necessarie.
5. L'applicazione legge il token ed esegue l'operazione.

In questo caso, sei preoccupato che il token al portatore, che scorre su Internet al browser dell'utente, possa essere sostituito con un token al portatore ottenuto in precedenza, per un utente diverso che potrebbe avere più permessi.

Tuttavia, non si desidera impedire completamente la riproduzione. Ad esempio, se il passaggio 4 non riesce a causa di un problema di rete, l'utente dovrebbe essere in grado di aggiornare la pagina e riprovare, e lo stesso token verrà nuovamente inviato. Questo è perfettamente OK.

Quello che vuoi evitare è che l'utente invii un token / artefatto da un altro utente. Oppure se le autorizzazioni dell'utente sono state revocate un giorno fa, non vuoi che l'utente invii il proprio token da due giorni fa.

Tutto ciò che ti serve è assicurarti

1. L'artefatto identifica l'utente
2. Gli identificativi delle risorse utente l'autorizzazione
3. L'artefatto indica un periodo durante il quale l'autorizzazione è concessa all'utente
4. L'artefatto è firmato in un modo che può essere validato

Se fai tutto quanto sopra, non è necessario bloccare la riproduzione. Bene, tecnicamente l'articolo 3 qui sopra include un intervallo di date, quindi è una specie di debole attenuazione del replay. Ma l'idea che ogni token debba essere generato nel contesto di una sfida casuale e di una risposta non è corretta: il server di identità deve semplicemente dichiarare ("asserire") che un utente, un permesso e una finestra temporale appartengono tutti insieme e firmarlo . Fare ciò impedirà il tipo di attacchi che penso tu sia preoccupato.

Per favore correggimi se le mie ipotesi non sono corrette.