Pull RLM_TOTP 6 digit commit in master to 3.2
Hi Just trying to get the TOTP module working on 3.2.x using the latest RPM package of 3.2.4.1 However noticed that the default config is 8 digits for the OTP Length in the 3.2 branch https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-avail... However this commit that was merged into master should be pulled into the 3.2 branch to default to 6 digits. https://github.com/FreeRADIUS/freeradius-server/commit/534d165e71ec87a526e0e... If you wanted to follow the rfc6238 spec to the letter then the default is: Hash: SHA1 Length: 6 Digits Time-step Size: 30 Seconds But I know there are various implementations that support: Hash: SHA1 or SHA256 Digit: 6 or 8 Digits Time-step Size: 30 or 60 Seconds Additionally if hardware TOTP tokens are being used there is an issue where the time set when manufactured can get wildly out of skew as I have had more than one device that arrived that wasn't synced to UTC. The worst I have seen was a hardware token over 3 minutes behind. So if someone was looking to make changes in the module adding a per device hardware skew with a set number of seconds plus or minus UTC such as: TOTP-HardwareSkew = -180 Or similar to set the number of seconds the particular hardware token is known to be out of skew. I know patches are always welcome, but pulling the commit into 3.2 would be appreciated. Would you like me to raise an issue on Github about this? Or update https://github.com/FreeRADIUS/freeradius-server/issues/4809 Cheers, Peter
On Jun 18, 2024, at 10:12 PM, Peter Lambrechtsen via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hash: SHA1 Length: 6 Digits Time-step Size: 30 Seconds
Sure, that makes sense. I'll push a change.
Additionally if hardware TOTP tokens are being used there is an issue where the time set when manufactured can get wildly out of skew as I have had more than one device that arrived that wasn't synced to UTC. The worst I have seen was a hardware token over 3 minutes behind.
So if someone was looking to make changes in the module adding a per device hardware skew with a set number of seconds plus or minus UTC such as:
TOTP-HardwareSkew = -180
Or similar to set the number of seconds the particular hardware token is known to be out of skew.
That makes sense.
I know patches are always welcome, but pulling the commit into 3.2 would be appreciated.
The rest of that commit isn't needed for v3.2, so I'll just make the length change.
Would you like me to raise an issue on Github about this? Or update https://github.com/FreeRADIUS/freeradius-server/issues/4809
Sure. Add a note about time skew, which is perhaps better than increasing the time window. Alan DeKok.
On Thu, Jun 20, 2024 at 12:09 AM Alan DeKok <aland@deployingradius.com> wrote:
On Jun 18, 2024, at 10:12 PM, Peter Lambrechtsen via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
Hash: SHA1 Length: 6 Digits Time-step Size: 30 Seconds
Sure, that makes sense. I'll push a change.
Much appreciated.
Additionally if hardware TOTP tokens are being used there is an issue where the time set when manufactured can get wildly out of skew as I have had more than one device that arrived that wasn't synced to UTC. The worst I have seen was a hardware token over 3 minutes behind.
So if someone was looking to make changes in the module adding a per device hardware skew with a set number of seconds plus or minus UTC such as:
TOTP-HardwareSkew = -180
Or similar to set the number of seconds the particular hardware token is known to be out of skew.
That makes sense.
I know patches are always welcome, but pulling the commit into 3.2 would be appreciated.
The rest of that commit isn't needed for v3.2, so I'll just make the length change.
Would you like me to raise an issue on Github about this? Or update https://github.com/FreeRADIUS/freeradius-server/issues/4809
Sure. Add a note about time skew, which is perhaps better than increasing the time window.
I've updated https://github.com/FreeRADIUS/freeradius-server/issues/4809 with some further feedback about enhancements and includes a few links to client side browser based online TOTP calculators. I'm 50/50 about if you should link to them but the Token2 one is good and supports all the different permutations on the one page and the Dan Hersamn version is a fully browser client side TOTP implementation on github so that could easily and safely be hosted somewhere on the FreeRadius site for testing purposes. Much appreciated as always. Peter
participants (2)
-
Alan DeKok -
Peter Lambrechtsen