Whonix workstation-based app qubes are now showing a consistent ~2-minute time difference compared to other qubes (including the offline Vault). This breaks 2FA (TOTP) on accounts accessed through Whonix.
The clock qube is set to sys-net, which is based on the Kicksecure template.
The offline Vault/KeepassXC is used for 2FA and is set to UTC.
This has been my setup for a long time, but it has only recently started causing problems.
Any solution?
Known thing, you should add KeePassXC into an offline qube whether whonix-ws or Kicksecure, then disable sdwdate:
I already have KeePassXC in an offline qube based on Fedora Minimal. I don’t want to use Whonix-WS or Kicksecure for KeePass because I need a minimal template just for KeePass and nothing else, whereas both of those templates come with a lot of applications.
Is there any solution for my current setup?
What if I disable sdwdate in the Whonix-WS-based app qube? My clock qube is already Kicksecure-based and uses sdwdate, so would disabling sdwdate in the Whonix-WS app qube reduce anonymity?
This is a tough one, since the clock being “wrong” is a feature, not a bug (it provides anonymity benefits when the clock is “wrong” by different amounts across multiple VMs and multiple reboots). You probably want the anonymity benefits of having a not-quite-exactly-correct clock system-wide, but you also need your vault VM’s qube to have a time matching that of the service you’re authenticating to.
There are a couple ways to get around this I can think of immediately:
The other alternative would be to not use Kicksecure or Whonix as a clock VM anymore, and only get the time anonymity benefits in Kicksecure and Whonix qubes.
I manually set the vault’s time to match the whonix-ws qube, and it resolved the issue. However, it seems I have to do it manually every time.
Is it possible to set the clock qube for this vaultto sys-whonix? That should fix the issue, I think.
That’s… curious. The vault’s time needs to match the time of the remote server that authenticates you, not the time of the machine doing the authenticating, otherwise anyone could make any TOTP code valid indefinitely. Unless your whonix-ws qube’s time happens to be close enough to accurate to work in this instance, I don’t understand how this would work. (Maybe it’s some weird interaction between bootclockrandomization and the default clock sync mechanism in Qubes? Or maybe I’m slightly misunderstanding sdwdate and the time it sets is the accurate time, and the “clock being wrong” thing is only used before sdwdate kicks in? I admit I’m hazy on the details of how this part of Whonix works.)
Not to my awareness, it looks like the ClockVM is a system-wide setting. What you might try though is running sudo systemctl disable bootclockrandomization.service in the template your vault is based on. Maybe that will solve the issue?
I don’t think so. I use TOTP for many services, and all of them require the time on the machine where the website is opened to match the time on the TOTP device, including GitHub.
When TOTP started causing problems, I contacted GitHub support. They explicitly stated that the time on my TOTP device must match the time on the machine where I am using GitHub.
I am using fedora-minimal for my vault, and it does not have this service. I should ask the Qubes community about this because dom0 periodically sends time sync commands to all running qubes. If it is possible to disable this, it can only be done from dom0.
I am curious about exactly what changed. I have been using the same setup since Qubes 4.2, and I have been using TOTP since then. Even after upgrading to 4.3 and kicksecure-18, the setup remained the same, and there were never any TOTP failures until recently. The only thing I needed was to set the Timezone of my TOTP VM to match the Timezone of the VM I am using the service on.
Is this time randomization a recent addition in Kicksecure? I can’t think of any other reason why everything was working fine before and not now.
If that was / is the case, anyone could use a TOTP code long after its expiration if only the time on the machine running the browser mattered (by simply setting their clock back). That’s the very thing TOTP is designed to prevent. I suspect GitHub is assuming that the clock of the machine accessing GitHub is accurate, and that your authenticator device’s clock is out of sync (which does sound like it’s the case, or at least not far from the truth).
It’s been there for as long as I’ve been working on Kicksecure and Whonix, well into Kicksecure / Whonix 17’s lifespan, so I don’t think so.
What you are saying makes sense. However, I tested this scenario. I set up a Fedora-based clock qube and synced the clock. Afterward, I compared the time difference between the vault and the Whonix-WS-based qube. The time was the same, but the timezones differed: the Whonix qube was set to UTC, while the vault was set to the local timezone. I checked the time online, and the vault was synced correctly, displaying the accurate time.
When I tested TOTP on my GitHub and X accounts, both rejected the codes. I then changed the vault’s timezone to UTC. After that, the time on both the vault and the Whonix qube was exactly the same, and TOTP worked successfully on both GitHub and X.
Now, if I misconfigure the time on the Whonix qube and match the vault to the exact time of the Whonix qube, TOTP will not work because the time is not accurate.
What I deduce from this is that TOTP requires both devices, the one where I am using the service and the one acting as the authenticator, to be in the same timezone, while the server checks the time accuracy.
Anyway, thanks for explaining all of this to me; I am genuinely grateful. I have been using Whonix since 2016, and I never knew about this clock randomization feature. It should be mentioned prominently in the pros of using Whonix.
Moderation comment: Please separte posts by topic (timesync, OTP versus homepage) as this forum thread will be split.
There’s a lot of information to communicate. The homepage feature slider seems not very effective, which may be consistent with research on that topic. (tirdad is mentioned inside the feature slider.)
So the carousel (feature slider) was a bad choice and needs to be replaced with something better one day.
It depends on the background of the visitor, how technical they are, which information they consider important. Visitors who don’t know what Tor is, versus intermediate users, versus advanced users, versus experts or developers. A scale similar to that.
Sorry, the comment was not intended for the website or the developers. It was simply a comment of praise.
Actually, I give presentations to businesses and individuals who need cybersecurity. I convince them to shift to Qubes OS + Whonix, and I personally maintain a list of the pros of using Whonix on Qubes OS. So, the last line of comment was mostly just thinking out loud 
The issue is resolved on the Qubes OS Forum by @unman :
set policy in some other qube to enable
clocksync. Set
policy for vault to use that qube.
qubes.GetDate * vault @anyvm allow target=QUBE
I added the clocksync service to sys-whonix, set target=sys-whonix, and my TOTP issue was resolved.