Come viene eseguita la risincronizzazione per le chiavi di sicurezza / dispositivi MFA?

Question

Come viene eseguita la risincronizzazione per le chiavi di sicurezza / dispositivi MFA?

#1 da (1 voti)

1

Quando una chiave di sicurezza del dispositivo MFA (basata sul tempo) si allontana dalla sincronizzazione, esiste una procedura per risincronizzarla. Ma non c'è input sul dispositivo stesso.

Le app per smartphone non hanno questo problema. Presumo che questo sia dovuto al fatto che l'app ha accesso all'orologio preciso dal / i fornitore / i di telco. I dispositivi con chiave di sicurezza devono avere un proprio orologio o fonte di tempo, che può essere attaccato (riceverlo tramite un segnale radio come WWV o CHU in Nord America) o deriva (orologio interno). Sto indovinando tutti i dispositivi che ho visto utilizzare un orologio interno, perché ci sono molti rapporti di loro che hanno bisogno di essere risincronizzati, spesso. Ma non è ovvio come questo sia fatto così rapidamente, o fatto in luoghi senza fonti di clock. Non è nemmeno ovvio il motivo per cui è necessaria un'impostazione amministrativa per risincronizzare il dispositivo.

Qualcuno può spiegare (o fornire un buon link che spiega) come il dispositivo viene risincronizzato? Voglio capire il livello di rischio che potrebbe avere.

synchronization time multi-factor

posta Skaperen 14.11.2017 - 07:46

fonte

1 risposta

Leggi altre domande sui tag synchronization time multi-factor

Accesso al database SQL dall'app Android Java. Come posso archiviare i dettagli del database SQL in modo che siano sicuri? I provider di servizi cloud offrono approfondimenti sui loro problemi di sicurezza?

score 1 · Accepted Answer

Per i token basati sul tempo ci sono fondamentalmente due metodi.

Prima di tutto, poiché l'ora In un token non può essere manipolata (o è un frob isolato con un orologio scadente o è ospitato su un sistema in cui non si può influenzare l'orologio).

Quindi ciò che deve essere fatto è sul server di autenticazione, si mantiene un offset di tempo stimato (o un modello di compensazione più complesso) e lo si regola su ciascun accesso.

Fondamentalmente si confronta l'input dall'autenticazione corrente con alcuni codici prima e dopo il codice corrente. Se corrisponde, conosci un offset da applicare la prossima volta.

Questo metodo di correzione può essere complicato quanto vuoi, dal momento che non vuoi consentire a un utente malintenzionato di influenzare le tue stime o non vuoi rendere la finestra troppo grande in quanto consente di indovinare più. (Ad esempio, conserva una cronologia delle ultime 3 autenticazioni e scostamenti ed esegui una regressione lineare per trovare non solo l'offset ma anche l'inclinazione della differenza)

Se decidi che la deriva del tempo è troppo grande (o non hai dati iniziali per la previsione) chiedi più voci. Ciò ridurrà il rischio di accettare un codice ripetuto (in un intervallo troppo ampio).

Per la registrazione iniziale probabilmente vuoi consentire un intervallo di tempo più lungo prima di rifiutare un token (tuttavia fai attenzione se il token ha un orologio rotto e accetti la registrazione potresti rischiare che un accesso futuro fallisca, che è più fastidioso di rifiuto di una registrazione del dispositivo)

Lo stesso identico meccanismo si applica anche ai sistemi basati su contatore (con l'ulteriore compito di tenere conto degli aggiornamenti del timer persi e sfortunatamente non mai negativi)