Windows 10 Desktop app FIDO2 Webauthn stuck on "Loading"

[timespaced]

I’m on the testing build of VaultWarden.

When trying to use FIDO2 WebAuthn login on the Bitwarden desktop app on Windows 10, the app displays “Loading” and never progresses. The following occurs in the vaultwarden logs:

[2021-10-26 10:07:37.321][request][INFO] POST /api/accounts/prelogin
[2021-10-26 10:07:37.321][response][INFO] POST /api/accounts/prelogin (prelogin) => 200 OK
[2021-10-26 10:07:37.358][request][INFO] POST /identity/connect/token
[2021-10-26 10:07:37.396][error][ERROR] 2FA token not provided
[2021-10-26 10:07:37.396][response][INFO] POST /identity/connect/token (login) => 400 Bad Request

The mobile apps and browser extensions work as expected with WebAuthn (including the browser extension for Firefox on the same PC as the Desktop app having this issue).

Vaultwarden is hosted on my server at home and only accessible on my local LAN. I followed the HAProxy for pfSense guide to set up the reverse proxy.

DOMAIN variable is set in Unraid Docker for VaultWarden. Domain is also set in admin panel. No trailing / on the domain (https://vault.mylocaldomain.com).

https://vault.mylocaldomain.com/webauthn-mobile-connector.html correctly resolves the WebAuthn image (which is suppose to appear in the desktop app).

I have removed all headers from pfSense HAProxy; same issue. I have tried to connect directly via IP:Port in the desktop app; same issue.

I looked at the official BitWarden GitHub and the desktop app seems to work as expected for them. This seems to be an issue specific to either VaultWarden or with pfSense/HAProxy maybe?

[BlackDex]

Posting this multiple times on different locations isn't going to help you. https://vaultwarden.discourse.group/t/windows-10-desktop-app-and-webauthn-not-working-mobile-browser-extensions-work-fine/1230/3 is pointing to two specific headers which could be the issue. I suggest to double check this and also, provide the support string.

[timespaced]

I dunno, seems to have helped already. ;) Truth is, I’m not sure where the best place to post it is. Further, you’ve change this from an issue to a discussion- why? Should bug/support be in discussion instead of issues? If so I’ll make sure to post in the correct spot next time.

As I said in the thread you linked, removing the headers did not solve the issue.

I don’t know what a support string is, can you please elaborate? Happy to provide it.

[BlackDex]

You can generate t string via /admin/diagnostics

[BlackDex]

And regarding the double posting. You just replied to that post 8h ago and then copied and pasted it here again. That is what i mend with not useful. Just be patient.

[BlackDex]

There is one simple solution for now, add file://* to the ALLOWED_IFRAME_ANCESTORS
So, either via a -e or ENV setting somewhere, or via the /admin portal under the Advanced Settings tab.

To conclude what was already mentioned at the Discourse discussion page, removing the Content-Security-Policy header is a solution, and if that didn't worked for you, you didn't removed the header. You can check that via the Browser Tools (F12) your self.

Though, removing that header is probably not very safe, so i suggest to just add the file://* item.
We may need to look into some special filtering for this within the code, but i do not think it is that big of an issue right now, since you are able to fix this easily.

An other solution would be to only remove this header for an URL which starts with /webauthn-connector.html, and keep it for the rest.
Depending on the reverse proxy there are probably some ways to do this.

[pduchnovsky]

For people using traefik middleware with frameDeny or customFrameOptionsValue headers enabled, that will cause this as well, so disable them both. As mentioned below, Vaultwarden is generating required and proper CSP by itself.

[BlackDex]

This has been fixed a long time ago already.
Some of the flags you set there might still cause issues with other Bitwarden clients btw.
Vaultwarden already sends all the headers needed to be as secure as possible and when needed.
Changing that, or overriding them might cause issues in the future.

[towade]

I still have the same problem with the desktop app on Windows 11.
ALLOWED_IFRAME_ANCESTORS is set to file://*.
I don't know where I can change the headers.

[BlackDex]

Webauthn should load within the desktop client, no popups or whatever.
And it seems to work ok for me, just tested it on a Windows 11 laptop with a clean profile.

[BlackDex]

Check /admin/diagnostics for issues.

[towade]

/admin/diagnostics shows:

API calls:
Header: 'x-xss-protection' does not contain '0'
Header: 'content-security-policy' does not contain 'default-src 'none''
Header: 'content-security-policy' does not contain 'font-src 'self''
Header: 'content-security-policy' does not contain 'manifest-src 'self''
Header: 'content-security-policy' does not contain 'base-uri 'self''
Header: 'content-security-policy' does not contain 'form-action 'self''
Header: 'content-security-policy' does not contain 'object-src 'self' blob:'
Header: 'content-security-policy' does not contain 'script-src 'self' 'wasm-unsafe-eval''
Header: 'content-security-policy' does not contain 'style-src 'self' 'unsafe-inline''
Header: 'content-security-policy' does not contain 'child-src 'self' https://.duosecurity.com https://.duofederal.com'
Header: 'content-security-policy' does not contain 'frame-src 'self' https://.duosecurity.com https://.duofederal.com'
Header: 'content-security-policy' does not contain 'frame-ancestors 'self' chrome-extension://nngceckbapebfimnlniiiahkandclblb chrome-extension://jbkfoedolllekgbhcbcoahefnbanhhlh moz-extension://*'
Header: 'content-security-policy' does not contain 'img-src 'self' data: https://haveibeenpwned.com'
Header: 'content-security-policy' does not contain 'connect-src 'self' https://api.pwnedpasswords.com https://api.2fa.directory https://app.simplelogin.io/api/ https://app.addy.io/api/ https://api.fastmail.com/ https://api.forwardemail.net'
2FA Connector calls:
Header: 'x-xss-protection' does not contain '0'
Header: 'x-frame-options' is present while it should not
Header: 'content-security-policy' is present while it should not

Its a Yunohost-Installation

[BlackDex]

Your main issue is Header: 'x-frame-options' is present while it should not under the 2FA Connector calls:
Fix your reverse proxy to not modify, add or delete headers for the Vaultwarden instance, as Vaultwarden sends all the needed headers for each endpoint when needed.

[towade]

Thx for you quick replay.

I just commented out the following lines in my yunohost /etc/nginx/conf.d/vault.XYZ.li.conf and it worked for me:

#    include /etc/nginx/conf.d/security.conf.inc;

#    more_set_headers "Strict-Transport-Security : max-age=63072000; includeSubDomains; preload";