Autenticazione HMAC del servizio Web / anti-replay

3

Sto creando un servizio web, che gestisce varie richieste da client web. Il client e il server condividono una grande chiave segreta S e quando una parte desidera inviare i dati, calcola il token come segue:

T = HMAC (corpo HTTP || Richiesta timestamp, S)

Quindi, quando una parte riceve la richiesta http, ricalcola T dal corpo http e la data / ora dal campo dell'intestazione della data http e la confronta con il digest HMAC ricevuto. Se i digest sono uguali E lo scostamento temporale del timestamp e il momento in cui la richiesta è stata ricevuta è inferiore a una soglia specificata, concedere la richiesta. Altrimenti negalo.

Questo è sicuro? Supponendo che l'autore dell'attacco non possa falsificare l'intestazione Data poiché è protetto dall'HMAC, più l'offset del limite di tempo (per la protezione della riproduzione), penso che sia ok.

Supponendo che il protocollo sopra non abbia difetti, quanto tempo dovrei impostare, l'offset della soglia valido? Supponi ad esempio che 5 secondi siano ok?

    
posta Dimitris Fousteris 27.03.2013 - 00:37
fonte

1 risposta

5

Se si esegue il protocollo su un semplice HTTP, gli hacker che interferiscono con la comunicazione potrebbero abbandonare, duplicare o riordinare le richieste, entro i tempi. Possono anche inviare al client (rispettivamente al server) alcune delle proprie richieste come se fossero risposte dal server - a seconda del protocollo, questo potrebbe o meno essere un problema, ma potrebbe essere devastante.

È possibile ridurre l'intervallo di validità delle richieste e delle risposte rifiutando i timestamp che sono spenti di una quantità eccessiva, ma ciò richiede che il client e il server siano sincronizzati correttamente, cosa che non può essere garantita su base generale (molti computer " là fuori "sono spenti da alcuni minuti, persino ore, persino anni in alcuni casi). Quindi non è possibile rendere sufficientemente basso il range di validità del timestamp per garantire una sicurezza decente. Per riassumere, il tuo protocollo non può essere davvero resistente contro gli attacchi di replay e le varianti, se giocato su un mezzo di trasporto non protetto come un semplice HTTP. Puoi fare alcune attenuazioni, in una certa misura, ma a costo di problemi di usabilità (a causa di una possibile mancanza di sincronizzazione dell'orologio).

La soluzione è quindi: usa SSL (alias HTTPS in un contesto Web). SSL ti darà tutta la protezione di replay che desideri; porta anche la crittografia. Con SSL, i tuoi HMAC fatti in casa diventano ridondanti e potresti semplicemente dimenticarli del tutto.

    
risposta data 27.03.2013 - 15:22
fonte

Leggi altre domande sui tag