Problemi nell'utilizzo di HOTP con finestra di iterazione

1

Sto utilizzando HOTP per generare OTP per convalidare una richiesta, al fine di impedire attacchi di riproduzione. Sto pensando di utilizzare una finestra di 10 (o così) iterazioni per far fronte a una possibile mancata corrispondenza nel contatore di client e server, ma sono un po 'preoccupato per il modo in cui dovrei trattare quelle iterazioni. Devo rifiutare ogni token che è inferiore all'ultimo contatore confermato? O posso avere un piccolo margine lì?

EDIT:

Il motivo per cui mi chiedo è perché sto facendo una "autenticazione a tre parti", con questo intendo che il proprietario del dispositivo si autenticherà inviando un token (con l'HOTP in esso) e un altro server lo userà per ottenere qualcosa da un server delle risorse (un po 'come oauth ma ...). Quindi se il proprietario del dispositivo autentica 2 server il contatore sarà 1567 e 1568, ma se il secondo server (con il contatore 1568) arriva prima al server di risorse, l'altro verrà rifiutato

Grazie.

    
posta Snox 15.04.2014 - 18:48
fonte

1 risposta

0

"OT" in "HOTP" significa "una tantum". Questo è vero solo se il server respinge effettivamente le password corrispondenti a un valore contatore che non è maggiore dell'ultimo valore confermato. Avere "un piccolo margine" qui significherebbe accettare che una determinata password venga accettata due volte, la stessa cosa che HOTP cerca di impedire .

Questo è tutto basato sull'idea che il proprietario di HOTP usi le sue password in modo sequenziale; non c'è mai una situazione in cui il proprietario avrebbe interesse a utilizzare una password che non è l'ultima prodotta dal suo dispositivo di generazione di password. Corrispondentemente, se il server ha ricevuto ad un certo punto la password corrispondente al valore contatore 1567, allora il server conosce che il dispositivo del proprietario è passato al valore 1568 e qualsiasi tentativo di utilizzare, ad esempio, la password 1565 sarebbe una sicura indicazione di gioco scorretto.

La "finestra" è verso il futuro, perché il proprietario del dispositivo potrebbe aver premuto inavvertitamente il pulsante alcune volte senza accorgersene, quindi forse la prossima password corrisponderà al valore contatore 1575, non 1568, e il server continuerà a funzionare accettalo.

In altre parole, il comportamento della finestra come specificato in RFC 4226 è il margine necessario. Non ci dovrebbe essere alcun margine nell'altra direzione; se c'è una tale necessità, probabilmente stai maltrattando male l'HOTP.

Modifica: se hai diversi server che utilizzano password monouso della stessa fonte, allora mi auguro vivamente che tu instradi tutte queste password in un unico server di autenticazione, che mantenga il valore contatore. (Se questo non è il caso, hai problemi molto più grandi.)

Se si teme solo che due di questi OTP possano raggiungere il server di autenticazione "fuori servizio", allora si può davvero rendere le cose un po 'più sciolte senza compromettere la sicurezza, ma richiede una certa attenzione. La proprietà importante di un sistema di password monouso è che ogni valore di password dovrebbe essere utilizzato una sola volta. Il valore del contatore, con la semantica spiegata in RFC 4226, è un modo economico ed efficiente per mantenere questa semantica: il server deve solo ricordare l'ultimo contatore visto, e questo è tutto.

Tuttavia, è possibile fare in modo che il server di autenticazione ricordi i valori della password effettivamente utilizzati. Questa può essere una "finestra all'indietro": in qualsiasi momento, il server ha un contatore corrente N , che è il valore del contatore più alto visto e ricorda tutti vede le password nel N-9 nell'intervallo N . Con una finestra di questo tipo, il server può ricevere le password un po 'fuori ordine: verrà accettata una password se il suo contatore M è maggiore di N , oppure è in Intervallo N-9 a N e non è stato ancora visto. La programmazione sul server è leggermente più complessa, ma non in modo insuperabile.

Nota importante: la "finestra a ritroso" è sicura nel caso di HOTP, ma non si estende solo a uno schema di "password unica". Questo è sicuro per HOTP perché HOTP è un MAC calcolato su un valore contatore - si basa sul contatore per non ripetersi , ma non sui possibili valori del contatore usati in ordine numerico. Lo stesso non sarebbe vero per schemi di password monouso che usano catene hash (dove ogni OTP è un hash del next uno). Quello che dico qui è solo per HOTP.

    
risposta data 15.04.2014 - 19:05
fonte