Thank you Thumbed or voiced from mobile device ...
On Fri, Dec 15, 2023 at 7:50 PM Michael Jumper <[email protected]> wrote: > On 12/15/23 13:59, Don Murdoch GSE BTHb wrote: > > Hello. > > I have a container based setup for Guacamole (guacd, mysql, guacamole). > > > > ... > > So - I dropped the TOTP part of the user account, logged back in, and > > got a new QR code. Using the same client side app I attempted to > > authenticate - and I still get he red banner at top "Verification > failed". > > > > Using Ravio OTP, I can see the SHA 1 key, the hash. All of the > > parameters match up fine. > > What could cause this? What do I do to fix this? > > > > I did notice that the 'date' in the containers is 8 hrs off from the > > host, but the date (Dec 15) is the same. > > The system clocks of your server and your authentication device(s) MUST > be accurate, down to the second. The time zone doesn't need to match; > the system clocks just need to represent the same point in time, > whatever that may be locally. > > A discrepancy of 8 hours will be more than enough to cause the codes to > not match. The authentication codes for anything implementing TOTP are > essentially generated by hashing the current timestamp after rounding it > down to the nearest N seconds, where N is the code generation period, so: > > * A time difference of greater than the generation interval will result > in the codes _never_ matching. > * A time difference of less than the generation interval will result in > the codes mysteriously only _sometimes_ matching. > > If your server and authentication devices disagree on the current time, > they will also disagree on generated codes. > > TL;DR: TOTP is time-based, so your system clocks MUST be synchronized > and accurate. It can't work if they aren't. No exceptions. > > - Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
