In these cases it makes sense to deem that TOTP as valid to prevent the prover from having to resubmit the TOTP. Say the prover submitted the TOTP close to the end of the time window of 30 seconds and given network delays, upon calculation on the verifier, that TOTP value is no longer the current, but the previous. This can also happen due to network delay. When the verifier generates the list of 3 TOTPs for the user, the one the prover provided is already in the past. The current TOTP for the prover is what the server sees in the middle of the window, since it now accepts TOTPs from 3 time windows current window, the previous and the next.īut when the prover’s clock is delayed relative to the verifiers, this is what it would look like: When both the prover’s and verifier’s clocks are in sync, this is what it would look like when the verifier allows one past window and 1 future window: Prover clock delays and verifier allowed windows If you want to use better random generators such as AWS KMS, you can implement your own SecretProvider and use such provider in the totpConfiguration of the DefaultTOTPService.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |