L'algoritmo TOTP si basa sull'ora del client che viene sempre sincronizzata correttamente?

Does the TOTP Algorithm rely on the client time always being synced correctly?

Sì

What happens if for some reason a cell phones clock / calendar is off by a significant amount of time? Does the TOTP (Time-based OTP) algorithm generate an invalid token?

Non sarebbero in grado di autenticare correttamente . Questo non è esattamente un token non valido , solo un token per un altro momento.

do time zones play a role in the token being correct

No

does both the client and the server talk to a Network Time Protocol server to ensure that everything is synced up?

No . Un server NTP è un modo per farne uno qualsiasi per ottenere l'ora giusta , ma tua nonna manualmente introducendo la data e l'ora correnti (e il dispositivo configurato nel fuso orario giusto) funzionerebbe allo stesso modo.

suppose there was a 5 seconds differential between server time and client time and my grand mother was typing the the code on her phone, and just taking a long time. How would be assess the amount of buffer time the user has to type the code and whether it's correct or not.

Il server può essere un po 'indulgente accettando alcuni passaggi temporali attorno a quello giusto (dal server POV) e utilizzando un passo temporale non troppo piccolo.

Ad esempio, con un intervallo di tempo di 30 secondi e accettando 3 TS sopra o sotto il server uno, dà a tua nonna 1,5-2 minuti di digitarlo. Aumentalo a 10 e le daresti 5 minuti ... È solo questione di stabilire per quanto tempo vuoi accettarli. Al contrario, ciò consente a una finestra di attacco maggiore di utilizzare fraudolentemente tale codice.

Per quanto riguarda l'inclinazione dell'orologio, si noti che è possibile registrare la differenza tra i codici previsti e quelli forniti e estrapolare l'inclinazione prevista da quella. Se al giorno 1 10:00, l'utente fornisce il codice per 09:58 e il giorno successivo il codice per 09:56, potrebbe dedurre che ha un disallineamento dell'orologio di 2 minuti al giorno e regolare di conseguenza l'aspettativa del server per questo utente ai vecchi valori che altrimenti non verrebbero usati (resettando correttamente quando l'orologio dell'utente è "fisso"). Questo calcolo aumenta notevolmente la complessità, però. La maggior parte delle volte, non penso che in genere dovresti farlo.

Also how are all clients ensuring that their timestamp starts at the same time that the server epoch instant starts?

L'algoritmo che entrambi accettano di utilizzare, imposta un tempo determinato da cui inizia l'istante (tipicamente l'epoca Unix).

È un comune malinteso che l'algoritmo TOTP sia comunque coinvolto in Google o viceversa. TOTP si basa sull'algoritmo HOTP, che è stato pubblicato nel 2005 in RFC 4226 .

L'algoritmo TOTP sostituisce il contatore dell'algoritmo HOTP con un intervallo temporale di 30 o 60 secondi. È definito in RFC 6238 .

Va notato che l'idea degli algoritmi xOTP era basata lungo prima che ci fosse il primo smartphone in circolazione. Nessun dipendente di Google è stato coinvolto nelle specifiche ma piuttosto diverse persone dai fornitori di hardware di token.

Google ha semplicemente adottato l'algoritmo TOTP per i dispositivi Android, per il quale non è stato progettato in primo luogo!

What happens if for some reason a cell phones clock / calendar is off by a significant amount of time? Does the TOTP (Time-based OTP) algorithm generate an invalid token?

No, non necessariamente! Capitolo 6 della RFC raccomanda una risincronizzazione, ovvero l'orologio nel dispositivo di autenticazione potrebbe andare alla deriva e il server di autenticazione dovrebbe ricordare la deriva del clock. Quindi nel tempo il dispositivo di autenticazione può avere un offset di segno, se l'utente utilizza regolarmente il dispositivo di autenticazione. Il mio progetto, il sistema di autenticazione privacyIDEA si prende cura di tale deriva del clock.

Also, do time zones play a role in the token being correct or does both the client and the server talk to a Network Time Protocol server to ensure that everything is synced up?

Come ha sottolineato Ángel, non è necessario pensare ai fusi orari, poiché le fasce temporali vengono utilizzate in base al tempo di sistema unix.

E poiché RFC 6238 è stato definito per i token hardware, non vi è alcuna raccomandazione di utilizzare NTP, dal momento che il token hardware non ha una connessione Internet ma solo un orologio al quarzo locale alimentato a batteria. Ovviamente, se implementi il tuo server, dovresti connettere il tuo server a ntp. E se stai eseguendo un'applicazione per smartphone come autenticatore, questo dovrebbe anche usare ntp.

So in other words if we wanted to bullet proof the design of the server to be sensitive to the above scenario how would we go about doing this? For instance suppose there was a 5 seconds differential between server time and client time and my grand mother was typing the the code on her phone, and just taking a long time. How would be assess the amount of buffer time the user has to type the code and whether it's correct or not.

Questo è definito nell'RFC . 5 secondi non importa, poiché cade nello stesso tempo. La tua autenticazione può controllare alcune fasce prima l'ora corrente e dopo l'ora corrente e quindi sapere se l'orologio (o l'utente) è un po 'lento o veloce.