2FA Stop working

[axd]

I've setup two factor authentication to admin access using Google Authenticator, but for some reason isn't working anymore, I'm logged out, everytime that I'm asked for the generated code it seems to be different, anyone has a similar issue?

Thanks.

[andryyy]

It is possible that your time offset is too large. Can you try ntpdate etc.?

[axd]

If you are asking about the ntpdate command, here's the result:

21 Aug 08:28:22 ntpdate[30618]: no servers can be used, exiting

Also I've tried the ntpdate-debian and this one doesn't return an error:

21 Aug 08:36:43 ntpdate[3281]: adjust time server 91.189.91.157 offset -0.008816 sec

[stevesbrain]

@axd

everytime that I'm asked for the generated code it seems to be different

That's normal behaviour - these are TOTP tokens (Time-based One Time Passwords), and they change every 30 seconds. Wouldn't be super useful if it was the same number every time (as then someone just has to capture that number once, and they've got access to your account) :smile:

That said, there shouldn't be a way for it to just stop working. The only circumstance that normally causes issues is, as @andryyy said, clock drift. Based on the ntpdate-debian package, your offset on the server is acceptable - but what about your client? The TOTP password is derived from a "key" and the current time. If the time between your client and the server is too far out of sync, that's where you'll encounter issues.

After checking this, if all is good in that respect, perhaps try a fresh browser (no cache/cookies/etc) to see if the issue persists there also.

[axd]

@stevesbrain When I was saying that it seems to be different I was referring to the code given by the Google Authenticator app.

I've tested in different browsers and no luck.

For some reason is it working now. Some idea why this wasn't working for future problems?

[stevesbrain]

Best idea I would have @axd would be time sync differences between phone/other device + the server. Possibly you were grabbing it out of phone at the tail end of the 30 seconds, then putting it in the server shortly after that, but the server may have been +/- 20 seconds different, such that another full cycle had expired before you put in the other code? Without knowing everything that went on, it is hard to say. But given your code worked now, I'd suggest it wasn't an issue with the secret key in storage, and therefore would have to be a time-based issue! :smile:

[JOduMonT]

Hi; this morning the OTP stop working for me too my server is timesync

# timedatectl 
      Local time: Wed 2017-08-23 08:42:27 CEST
  Universal time: Wed 2017-08-23 06:42:27 UTC
        RTC time: n/a
       Time zone: Europe/Amsterdam (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

my phone seams having the same time I did a docker-compose reboot but still not able to connect

By any chance someones know how to desactivate this function ?

Regards!

Jonathan

[stevesbrain]

Hi @jodumont - all the relevant stuff should be in the mailcow DB container (I think it was a table called "tfa" from memory). You should be able to drop it out of there (definitely back up before doing so in case I'm wrong or it doesn't work).

The only other thing I know of that can stop this working is if the hostname changes. Is this possible in your instance?

Edit: yeah, looks like it's called TFA:

function get_u2f_registrations($username) {
  global $pdo;
  $sel = $pdo->prepare("SELECT * FROM `tfa` WHERE `authmech` = 'u2f' AND `username` = ? AND `active` = '1'");
  $sel->execute(array($username));
  return $sel->fetchAll(PDO::FETCH_OBJ);
}

[JOduMonT]

@stevesbrain thanks for you're follow I figured it was in the DB :)