HMAC: Quanto deve essere unico un nonce se anche la data fa parte della firma?

È necessario prendere in considerazione la finestra temporale consentita (per compensare la deriva dell'Orologio). Se si consente Data con una finestra temporale di più / meno 10 minuti (totale: 20 minuti), è necessario utilizzare nonces che sono univoci nell'intera finestra temporale e inoltre è necessario archiviare i dati spenti da quel periodo di tempo.

Per evitare una situazione di gara in cui un nonce viene cancellato dalla lista "speso" Prima dell'intestazione Date: del nonce utilizzato è diventato non valido, sarebbe consigliabile memorizzare i punti esauriti degli ultimi 40 minuti, e anche usa nonces che sono unici per 40 minuti.

Allora hai una soluzione praticamente a tenuta stagna.

In altre parole, se si consente di riutilizzare un nonce dopo 1 secondo, un utente malintenzionato può semplicemente inviare nuovamente la vecchia richiesta con l'intestazione della vecchia data, poiché se si consente una finestra temporale, che è necessario perché non è possibile garantire la client Clock è sincronizzato con il server, quindi accetteresti una richiesta con un nonce speso.

Se vuoi davvero un buon nonce, usa H (Time, Nonce) dove H è una decente funzione di hash. Quindi puoi usare nonces "non univoci" purché tu non generi 2 uguali uguali lo stesso secondo. Quindi ottieni hash univoci da usare come nonces.

Non intendo essere sincero, ma mentre stai inventando il tuo algoritmo di autenticazione, quasi certamente lo incasinererai e sarà soggetto a molti tipi di attacchi. Vi suggerisco caldamente di studiare i documenti di ricerca disponibili e gli algoritmi di autenticazione crittografica noti prima di crearne uno personale in modo da sapere quali errori non devono essere commessi. Inizia con l'autenticazione Kerberos, quindi Zero Knowledge Proofs, quindi SSL / PKI.

Detto questo, per rispondere alla tua domanda, sia il client che il server dovrebbero generare dei non probabili (o garantiti) da utilizzare una sola volta per la finestra temporale. Nonces devono essere utilizzati una volta (numero una volta). Un numero casuale sufficientemente ampio serve a tale scopo e non è necessario memorizzarlo. Avere sia client che server generano un nonce (2 differenti nonce) significa che entrambi riducono la possibilità di un attacco di replay dall'altra parte.

Inoltre, non vuoi che il tuo server di autenticazione diventi un Oracle (assista un client che attacca con indovinare le password degli utenti) o un server spoofing che rompa le password degli utenti (indovina un cliente a rivelare la sua password), quindi devi essere attento come progetta il tuo algoritmo. Il numero minimo di passaggi richiesti per un algoritmo di autenticazione è four .

1. c-s: ciao, sono client + nonce_c.
2. s-c: client-challenge + nonce_s.
3. c-s: client-response + server-challenge.
4. Server-risposta.

Vedi l'algoritmo di cui sopra? Il client dice chi è (Step 1) che include il client nonce, quindi (Step 2) il server chiede al client di dimostrare qualcosa che il server ha generato utilizzando sia il nonce del client, un autenticatore del client memorizzato (hash della password, ad esempio) e un server generato nonce. Il passaggio 3 dimostra il client al server. Il passaggio 4 (che molti dimenticano) dimostra il server al client; un passo importante per proteggere i tuoi clienti da attacchi di server falsificati (man in the middle e dns spoofing).

Con questo tipo di algoritmo, non è necessario archiviare nonces o preoccuparsi di riutilizzarli entro una finestra temporale. Invece, rendili sufficientemente grandi e casuali - insieme il client e il server partecipano alla creazione di un nonce con proprietà sufficientemente sicure.