iOS app unable to sync

[zacknewman]

Normally I would create a bug if I was certain this was an issue with Vaultwarden; however my fork of Vaultwarden has deviated so much, that there is a non-negligible chance the issue is with my fork. If I were a betting man though—which I am—I'd wager money this issue affects Vaultwarden too.

Anyway, I integrated the recent changes made to 1.32.1; notably #4932 and #4937. The affected functions are never called when logging in for the first time though which leads me to believe validation needs to occur other places. In particular api::core::ciphers::sync is called, but there were no changes to it.

Wanted to start a discussion as a way to potentially share ideas. If there is definitely not an issue with Vaultwarden, then the problem is mine alone so feel free to close this discussion. If this issue potentially affects Vaultwarden, then it would be nice to discuss which functions I should be looking for. Currently I'm spraying println in a bunch of places to see which functions do and do not get called.

[BlackDex]

If anything, it might be linked to #4932.
But that is only run during sync when the ciphers are converted from there struct to json representation.

Best to start with is checking if you see anything out of the ordinary in the response of the sync call. Doesn't matter if it is from the web-vault or via your ios device. The result should be the same.

And see if you have any strange passwordhistory items even after the fixes.

I would really love to know if you find anything. Because i have not yet been able to reproduce this my self, or see anything strange yet in files sent to me by users.

[zacknewman]

As stated, I'm using a lot of println calls; so I already have the JSON api::core::ciphers::sync sends to the client; however it's not obvious what is considered "out of the ordinary". There is certainly a lot of null values, but I don't know which are problematic.

Do you happen to know the typical sequence of API calls? As stated, api::core::ciphers::sync is called; however I'd like to know what the next function calls would be to narrow down the last API call as presumably it is the problem. Obviously I can read the source code for the iOS app, but I was hoping for a "shortcut".

[zacknewman]

I'll verify, but my fork should be up-to-date with 1.32.1. I only have code for TOTP and WebAuthn as I prefer to not include code I don't want—one reason why it's not correct of me to create an issue since my fork can hardly be called "Vaultwarden". I'll double check that the JSON that is sent for TOTP and WebAuthn is the same.

But regarding the 2FA, are there any errors on the Vaultwarden side? Maybe some differences in json key cases still somewhere?

I've only spent time trying to figure out the sync issues, but I'll quickly check now about the 2FA. To emphasize again, the current Android app, Firefox extension, and web vault don't have issues syncing or with WebAuthn and TOTP 2FA. These issues only affect the current iOS app. I can't recall the last time I used the iOS app before today, but I imagine it's been at most 2 or 3 weeks and it was fine then.

[zacknewman]

For WebAuthn, the authentication challenge is created (i.e., api::core::two_factor::webauthn::generate_webauthn_login is successfully called); but the ceremony is never completed (i.e., api::core::two_factor::webauthn::validate_webauthn_login is never called). api::identity::twofactor_auth is only called once. I wonder if Bitwarden finally fixed the "hack" where an error is (ab)used to indicate 2FA forcing clients to re-try.

Specifically, the way things are currently designed, twofactor_auth should be called exactly twice when 2FA is enabled. First time causes _json_err_twofactor to be called which errors and informs the client that 2FA is enabled and what forms are enabled. Second time twofactor_auth is called data.two_factor_token is populated allowing the WebAuthn ceremony to complete.

Perhaps it's something else. Seeing how twofactor_auth is not called twice though, I'm guessing the JSON error that is returned after the first call is the problem. Weird that the Firefox extension works though seeing how it's been updated too.

[BlackDex]

So, on my Android i have no issues at all regarding this. Both WebAuthn and TOTP.
I was using version: 2024.10.0 (19290) which i downloaded from here https:/bitwarden/android/actions/runs/11263511400

So, i doubt that they have fixed that.
It could be the JSON which your Vaultwarden returns and causes an issue.

As a reference it should look something like this (I have all 2FA options enabled and configured):
Also note the case of the keys here, those are important.

{
    "MasterPasswordPolicy": {
        "Object": "masterPasswordPolicy"
    },
    "TwoFactorProviders": [
        "0",
        "1",
        "2",
        "3",
        "7"
    ],
    "TwoFactorProviders2": {
        "0": null,
        "1": {
            "Email": "vw*****@domain.tld"
        },
        "2": {
            "AuthUrl": "https://api-4f2dbfa5.duosecurity.com/oauth/v1/authorize?response_type=code&client_id=D...J&request=eyJ---.eyJ---"
        },
        "3": {
            "Nfc": true
        },
        "7": {
            "allowCredentials": [
                {
                    "id": "9h...-u...5-O...g",
                    "type": "public-key"
                },
                {
                    "id": "B7...-...vQ",
                    "type": "public-key"
                }
            ],
            "challenge": "pQ...-...uD-...bw",
            "extensions": {
                "appid": "https://vw.domain.tld/app-id.json",
                "getCredBlob": false
            },
            "rpId": "vw.domain.tld",
            "timeout": 60000,
            "userVerification": "discouraged"
        }
    },
    "error": "invalid_grant",
    "error_description": "Two factor required."
}

[zacknewman]

Ugh, what an idiot. I never changed TwoFactorProviders to be an array of strings; instead it was an array of integers. Now both TOTP and WebAuthn 2FA work. Sorry for this. I think there is still an issue with sync, but clearly I cannot be trusted that I didn't forget something on my side.

If I happen to figure out how to fix sync, I'll report back; and perhaps it can help you. Until then, just ignore this discussion as it could very well be isolated to my fork. Thanks for the help.

[BlackDex]

I have an iOS device now. But my first attempt to sync with my private vault worked just fine.
Now going to see if i can reproduce the same on my dev environment, but I'm afraid it will be difficult.

Any feedback would be great! Thanks!

[BlackDex]

@zacknewman, how is your SSL configured for the app?
Could you maybe use some local tools like sslyze or testssl.sh and check if there are any SSL issues?

Both tools should show a list of compatibility with clients like iOS for example.
While i do not think that would be an issue, since you are able to login, who knows what further down the line could be causing an issue.

[zacknewman]

Yeah, once I sent that that stood out. Ugh, I thought I converted all the PascalCase to camelCase already. I'll have to properly vet all of the JSON to see if there is somewhere else I missed.

[zacknewman]

FYI,

Vaultwarden has a typo in how TwoFactor is serialized (Oobject instead of object).

Also the JSON you sent for the two factor stuff is still PascalCase (e.g., MasterPasswordPolicy). Mine is too, and the iOS app worked. Is that intentional?

[BlackDex]

Ah, thanks for the typo notice.

And strangely yes. It's either something Bitwarden forgot, or they need it for something else in the PascalCase format.
But it is both on the Android and iOS client. And the Bitwarden SaaS also still sends it this way.

Converting it to camelCase will break the mobile clients.

[zacknewman]

OK, there were a couple other places that I somehow missed; anyway, I am able to successfully sync now. Thanks for your time. I apologize for starting this discussion as it's one's responsibility to fix their own self-inflicted issues. I'll exercise better judgement next time before hastily starting a discussion. I foolishly convinced myself because I saw other people having issues that it was a shared one. Again, thank you.

[BlackDex]

np. Sometimes it's good to reflect. And, you found a type in the process.