MFA setup fails on iOS because displayed TOTP seed differs from stored temporary database seed

[abraxas-von-abrasax]

MFA setup fails on iOS because displayed TOTP seed differs from stored temporary database seed

Description

We are self-hosting HumHub and have installed/configured the official MFA module.

When users sign in, they are redirected to the MFA setup screen where they can scan the TOTP QR code. We observed that MFA setup works correctly on Android devices, but fails on iOS devices.

The issue appears to be that the TOTP seed shown to the user on the frontend differs from the temporary seed stored in the database on iOS.

Observed behavior

During MFA setup, the temporary TOTP secret is stored in the database in the following location:

• Table: contentcontainer_setting
• Key: twofaGoogleAuthSecretTemp

On Android devices, the seed stored in the database matches the seed displayed on the frontend / encoded in the QR code. As a result, entering the TOTP code generated by the authenticator app successfully completes the MFA setup.

On iOS devices, however, the seed displayed on the frontend / encoded in the QR code appears to be different from the seed stored in the database under twofaGoogleAuthSecretTemp. Because of this mismatch, the generated TOTP code is rejected, and the user cannot complete MFA setup.

Since the MFA setup cannot be completed on iOS, the temporary seed is never moved from twofaGoogleAuthSecretTemp to twofaGoogleAuthSecret.

Expected behavior

The TOTP seed displayed to the user / encoded in the QR code should always match the temporary seed stored in the database during setup, regardless of the client device, operating system, or browser.

Users on iOS should be able to scan the QR code, enter the generated TOTP code, and complete MFA setup successfully.

Actual behavior

On iOS devices:

1. The user is redirected to the MFA setup screen.
2. The user scans the QR code with an authenticator app.
3. The authenticator app generates a TOTP code.
4. The user enters the code in HumHub.
5. HumHub rejects the code.
6. The user cannot complete MFA setup.
7. The temporary seed remains stored under twofaGoogleAuthSecretTemp and is never moved to twofaGoogleAuthSecret.

After checking the database, the stored twofaGoogleAuthSecretTemp value does not match the seed shown/used on the frontend.

Steps to reproduce

1. Set up a self-hosted HumHub instance.
2. Install and configure the official MFA module.
3. Sign in with a user who has not completed MFA setup yet.
4. Open the MFA setup screen on an iOS device.
5. Scan the TOTP QR code with an authenticator app.
6. Enter the generated TOTP code.
7. Observe that the code is rejected.
8. Compare the seed shown/encoded on the frontend with the value stored in contentcontainer_setting under key twofaGoogleAuthSecretTemp.

Additional observations

• The same flow works correctly on Android.
• On Android, the frontend seed and database seed are identical.
• On iOS, the frontend seed and database seed are consistently different.
• The issue affects multiple browsers tested on iOS (tested on: Chrome, Safari, Firefox, Vivaldi).
• Since all browsers on iOS are required to use WebKit, this may point to an iOS/WebKit-specific behavior rather than a browser-vendor-specific issue.
• This prevents affected users from completing MFA setup.

Environment

• HumHub version: Professional Edition 1.15.5
• MFA module version: 1.1.3
• PHP version: 8.2.31
• Database: MariaDB 10.11.14-MariaDB-0+deb12u2-log
• Server OS: Debian 12 (bookworm), Linux Kernel: 6.1.164-1
• Affected client OS/browser: iOS / Chrome, Safari, Firefox, Vivaldi, Brave
• Working client OS/browser: Android / Chrome, Firefox, Vivaldi, Brave
• Authenticator app used on iOS: Microsoft Authenticator

[ArchBlood]

You're using a rather outdated HumHub version as well as module version, is there a reason you've not updated to newer version that could have already fixed this issue? 🤔

[abraxas-von-abrasax]

Hi, we did that of course, too. After updating HumHub to the latest stable version and the MFA plugin—Two-Factor Authentication (2FA)—to the latest version that supports HumHub v1.18.3, the issue still persists.

• HumHub Professional Edition: 1.18.3
• MFA module version: 1.2.2

[luke-]

@mbumpalumpa Can you please try to reproduce?

[mbumpalumpa]

@luke- I can't reproduce this. I tried it on my test instance and also spun up a new one. On both instances, I tested scanning the QR code and manually adding the secret to Microsoft Authenticator, and both worked without any issues. The only way I was able to reproduce the issue was by changing my iPhone's time from automatic to manual and moving the clock two minutes ahead.

Temporary Secret

Confirmed Secret

---

@abraxas-von-abrasax Can you confirm that, between generating the secret, scanning the QR code, and returning to HumHub, the page was not refreshed? For example, if the browser or app was minimised, or fully closed and reopened, the page may reload. If that happens, HumHub will generate a new secret code/seed, which would create a mismatch and cause the code generated from the previously scanned QR code to be rejected.

[abraxas-von-abrasax]

Hi @mbumpalumpa !

We have further investigated the problem and were able to identify and reproduce the cause of the issue.

During the MFA setup flow on iOS/Safari, the browser requests /manifest.json. In our environment, this request returned a 302 redirect to /twofa/check.

The relevant request sequence was:

GET /twofa/check    -> 200
GET /manifest.json  -> 302
GET /twofa/check    -> 200

The second request to /twofa/check appears to regenerate or overwrite the temporary TOTP secret. As a result, the secret shown in the QR code no longer matches the value stored in twofaGoogleAuthSecretTemp, and the generated verification code is rejected.

On Android, /manifest.json returned 200, so /twofa/check was only requested once and the MFA setup succeeded.

As a workaround, we added a physical manifest.json file and ensured that /manifest.json returns 200 without redirecting into the MFA flow. After doing this, MFA setup on the iPhone immediately worked.

This appears to confirm the earlier hypothesis that the page is effectively being requested a second time. However, it is not caused by a user-initiated refresh. Browsers on iOS request /manifest.json, receive a 302 redirect to /twofa/check, and then follow that redirect. This results in a second request to the MFA route and appears to regenerate or overwrite the temporary TOTP secret.