Allow TOTP as 2FA alternative if hardware security key can't be used

[taivlam]

Describe the bug From a UX perspective, a user will be prevented from proceeding from logging into their account if they use hardware security keys to log into their accounts but (for whatever reason) cannot get Android to detect a valid hardware security key.

To Reproduce Steps to reproduce the behavior:

1. Add at least 1 security key to your Standard Notes account from the web app.
2. Sign into your Standard Notes app on Android.
3. The hardware security key prompt screen appears.
4. See error.

Expected behavior There should be a UX fallback option to TOTP authentication, in case the default 2FA method of hardware security keys cannot work for whatever reason.

Screenshots If applicable, add screenshots to help explain your problem.

Screenshot:

Other than the "Cancel" button, the only action a user can perform here is press the "Authenticate" button.

Smartphone:

• Device: Pixel 5a (barbet)
• OS: GrapheneOS/Android 14
• App: F-Droid/Droid-ify
• Version: 3.195.1

Additional context

• This issue will be noticed by SN users who use security keys, especially if an Android user is on GrapheneOS with no sandboxed Google Play Services.
  • (From what I understand, Android with system-level Google Play Services can handle hardware security keys/passkeys.)
• I use SoloKey 1 and SoloKey 2 devices as my hardware security keys.
• I have the Professional plan for Standard Notes (which allows for hardware security keys as a 2FA method).

[taivlam]

In order to bypass this UX issue, I have to do the following:

1. Remove all hardware security keys on my Standard Notes account via the web app.
   • (This is so that Standard Notes can only use TOTP as 2FA.)
2. Sign into my Android device with TOTP.
3. Add back all my security keys via the web app.

This is a bit cumbersome, as it is currently is.

[CongL415]

Having a similar issue with the Desktop app (version: 3.195.13). My current workaround is to use the recovery code to bypass the security key authentication which does not work properly with the desktop app. Will be great to have a fallback mechanism or let the user to choose the suitable 2FA based on client.

[CongL415]

I think the problem comes from this line which hardcoded the U2F_IFRAME_ORIGIN variable.

Apparently my own web app is hosted on a different domain than the one hardcoded in the U2FPromptIframeContainer.tsx, the authentication will be failed.

I am wondering whether it is possible to allow self-host user to define U2F_IFRAME_ORIGIN by themself?