Timesync feature

[nphoe]

Hi,

First of all thanks for a great library.

Looking at verifyCode() I came to a conclusion this library could allow for syncing server to a client which is off by an unknown number of seconds. This can be achieved by allowing to pass a second code argument to verifyCode and matching both codes on each iteration within a wider discrepancy range. Now of course these to codes must be valid for two consecutive timeslices in correct order. Then we could return the number of seconds off from current time, having known the iteration count and period. This offset could then be saved with client's secret and be used to account for their time discrepancy during future authentications in an environment where correct time sync cannot be maintained. If I am correct, passing the corrected time to verifyCode is then all it takes to be able again to verify single code from such a client.

What do you think?

[RobThree]

Although, in theory, your idea would work, I think in practice it's an edge-case that isn't worth the effort. Most devices that run authenticator apps are online in one way or another and are time synced anyway. And those that aren't will run into other problems as well (such as SSL/TLS requiring your time being (mostly) correct).

What I'm trying to say is I don't think it's this library's responsibility to try and compensate for these kinds of issues. But even if you insist, it's still doable by implementing the logic 'outside' of this library; just invoke verifyCode as many times as you need/want and do it again for a second code; the specific timeslice(s) you'll want to test against are available to you as an argument to verifyCode.

[willpower232]

As Rob says, this definitely sounds like an application problem rather than a library problem.

I've recently worked on a similar issue using physical OTP tokens which were each off by a different amount of entire timeslices. I wanted to keep the number of timeslices to a minimum per token (hoping that they didn't get even slower) so I ended up doing something like this to detect and store the offset.

$found = false;
$discrepancy = 0;
while ($found === false) {
	$found = $tfa->verifyCode($tokenSecret, $code, ++$discrepancy);
	if ($found === false && $discrepancy >= 10) {
		$this->error('discrepancy too big, code correct?');
		return false;
	}
}

[nphoe]

As Rob says, this definitely sounds like an application problem rather than a library problem.

I've recently worked on a similar issue using physical OTP tokens which were each off by a different amount of entire timeslices. I wanted to keep the number of timeslices to a minimum per token (hoping that they didn't get even slower) so I ended up doing something like this to detect and store the offset.

$found = false;
$discrepancy = 0;
while ($found === false) {
	$found = $tfa->verifyCode($tokenSecret, $code, ++$discrepancy);
	if ($found === false && $discrepancy >= 10) {
		$this->error('discrepancy too big, code correct?');
		return false;
	}
}

If this snippet shows an example of validating the second code, wouldn't such a blind search without additional constraints result in validating a pair of any two codes, both of which do validate within a range of timeslices? If so, that approach starts to open up for a bruteforcing attack, where an attacker may use one expired code while trying to guess the second one. The second code would only need to fit into any timeslice within the inspected range of timeslices, no matter the order and disregarding the fact the codes must be consecutive.

Nonetheless, I do agree the requirement to validate an offset client with two codes can be achieved by a second call to verifyCode. Thanks for that! Only I need to pay close attention to the timeslices both of the codes belong to.

[willpower232]

I'm using this as part of "enrolling" the physical token into the database, detecting how wildly out of time it is and then when authenticating the user, I know what discrepancy is required.

I set a limit of 10 so that it broke the infinite loop but you wouldn't need a loop at all for authenticating the user as you can preserve the last successful timeslice to prevent reusing old codes.

[RobThree]

@willpower232 What you're doing by increasing the discrepancy like that is actually quite some 'extra work' (though it's negligible unless you're doing it for thousands of users). Because every iteration you increase discrepancy you check codes for:

iteration	verify code for timestamp (t)
1	t
2	t-1 t t+1
3	t-2 t-1 t t+1 t+2
4	t-3 t-2 t-1 t t+1 t+2 t+3
...	...
8	t-7 t-6 t-5 t-4 t-3 t-2 t-1 t t+1 t+2 t+3 t+4 t+5 t+6 t+7
9	t-8 t-7 t-6 t-5 t-4 t-3 t-2 t-1 t t+1 t+2 t+3 t+4 t+5 t+6 t+7 t+8
10	t-9 t-8 t-7 t-6 t-5 t-4 t-3 t-2 t-1 t t+1 t+2 t+3 t+4 t+5 t+6 t+7 t+8 t+9

(or something like that)

I think the better approach would be keeping the discrepancy at 0 and increasing the timeslice 10 times.

[willpower232]

I'm using this as part of "enrolling" the physical token into the database, detecting how wildly out of time it is and then when authenticating the user, I know what discrepancy is required.