La specifica OpenID Connect richiede client di flusso implicito per generare e convalidare un nonce:
String value used to associate a Client session with an ID Token, and to mitigate replay attacks.
Quali attacchi di replay sono quelli?
Metti diversamente, qual è l'impatto sulla sicurezza di non convalidare nonce quando si utilizza il flusso implicito?
Dare un'idea selvaggia dei pacchetti di riproduzione e dell'uso di nonces. Questo Dosen non ha a che fare con OpenId la mia idea generale.
Supponiamo nella comunicazione di due parti A e B; A sta condividendo la sua chiave con B per dimostrare la sua identità ma nel frattempo Attaccante C ascolta la conversazione tra loro e conserva le informazioni necessarie per dimostrare la propria identità a B.
In seguito C contatta B e dimostra la sua autenticità.
Esempio: se A ha una cache nonce che memorizza un numero nonce casuale pseudo.B lo usa direttamente per creare il pacchetto di risposta. A che cancella la cache quando ottiene il primo pacchetto di risposta da B.
Per la prossima trasmissione di nuovo, un nuovo nonce casuale viene salvato nella cache nonce di A. E usato per trasmettere pacchetti a B.
Se C dopo alcune volte prova a riprodurre un pacchetto in A. A scarterà a causa di nonce sbagliato.
Nota: Nonces può essere crittografato e inviato. Ci possono essere diversi modi per usare nonce secondo il protocollo.
La mia attuale comprensione è la seguente:
Il client (un'applicazione Web in esecuzione nel browser dell'utente) genera un nonce, lo inserisce nella memoria della sessione del browser e reindirizza al server di autenticazione, passando il nonce come parametro. Dopo l'autenticazione, il server di autenticazione reindirizza nuovamente al client, passando un token ID firmato contenente il nonce, che il client deve convalidare rispetto al nonce dalla memoria di sessione.
Se il nonce non è convalidato, un utente malintenzionato può sostituire un altro token ID, inducendo l'utente a visitare il suo sito e inviando un reindirizzamento con un token ID valido ottenuto da una richiesta diversa.
Oltre al token ID, anche il server di autenticazione risponde con un token di accesso. Se il nonce non è convalidato, un utente malintenzionato può sostituire un diverso token di accesso, ingannando l'utente sul suo sito e reindirizzandolo con quel token. Questo potrebbe essere utilizzato per un attacco Denial of Service lato client (in particolare se le schede del browser condividono l'archivio token, ovvero utilizzare l'archiviazione locale anziché quella di sessione).
In sintesi, la convalida nonce è necessaria per fidarsi del token ID. Se il token ID non deve essere considerato attendibile, la convalida non valida può essere saltata.
Leggi altre domande sui tag authentication openid-connect nonce