itflow
itflow copied to clipboard
Google Secret key producing wrong OTP
Describe the bug When entering the secret key to generate OTP for google, the code is wrong
Can you reproduce this on the demo at demo.itflow.org Yes
Are you on the latest available version of ITFlow, with an up-to-date database structure? Yes
To Reproduce Login to a google account and setup MFA, get the secret key from the qr code or the key they give as an alt to scanning the qr code
Expected behavior The qr code being correct
Screenshots N/A
Additional context None
Hey @mmxpy. Are you able to reproduce this issue on other 2FA providers? I'm trying to see here if this is an issue with your setup (usually server timezone related) or maybe Google now uses non-standard (i.e. not 30s) rolling 2FA codes. I've had trouble using Sophos SSL VPN 2FA codes on anything that isn't the Sophos app, for instance.
Yes I also get wrong MFA codes with O365 Azure Accounts even when selecting use another authenticator app, i.e. not Microsoft Authenticator
Ah I see, this is likely a time issue then - Could you check the server time is correct, please? Even just being a minute or so out will give an "invalid" code (the code would be valid, but not for right now!).
Hi @mmxpy were you able to confirm if it is an issue with time?
I've got the same issue.
ntpdate -q pool.ntp.org
server 162.159.200.123, stratum 3, offset -0.004679, delay 0.02715 server 13.55.50.68, stratum 3, offset -0.004749, delay 0.03801 server 162.159.200.1, stratum 3, offset -0.004652, delay 0.02657 server 129.250.35.250, stratum 2, offset -0.000147, delay 0.03847 10 Aug 10:51:31 ntpdate[682900]: adjust time server 129.250.35.250 offset -0.000147 sec
I'm changed out the TOTP library and seems to work. It's a hackjob, but will do until someone who knows what they are doing.
https://github.com/jcpit/itflow/commit/d249f90aa6aeb5337622be4feb4244175fa80ded?diff=unified
Fantastic work @jcpit this does indeed fix the issue, the code is fantastic! for a pull request, but please move the totp JS ibrary from the CDN to the plugins folder as we do not like to include remote assets if we don't have to. Keep up the great work. My time working on this community project has been increasingly narrow any more and the community project could use some great coders like you.
So discovered in my usage of the system that dispensers of the base32 token shared secret dispense them with lowercase alphabeticals, which the base32static.php
library doesn't tolerate, even though RFC 4648 explicitly states "... arbitrary sequences of octets in a form that needs to be case insensitive ..."
I can't be sure if this is the cause of the issues others are having, but I've submitted anyway. In effect it makes the call to base32static case insensitive.