App immediately crashes after unlocking vault

[reydus]

Subject of the issue

When unlocking the vault, once you have logged in, you type your master password, and after hitting the button, it immediately crashes.

This is very similar if not identical to issue #1169, however it didn't get solved after updating both the app and the server.

Your environment

• Bitwarden_rs version: 1.17 (latest as of 19/10/2020)
• Install method: Docker
• Clients used: Bitwarden from the Play Store, on Samsung's One UI 2.0 (Android 10)
• NGINX reverse proxy
• postgres

Steps to reproduce

Log in as normal
Lock the vault
Input the CORRECT master password and hit button.

Expected behaviour

The main screen with the vault content shows up.
*If a wrong password is inserted, it will say wrong password.

Actual behaviour

it immediately crashes (it goes to home screen for me, no messages)

Relevant logs

Here's a adb logcat:

10-19 00:14:17.606 24415 24415 I MonoDroid: System.Exception: PBKDF2 iteration minimum is 5000.
10-19 00:14:17.606 24415 24415 I MonoDroid:   at Bit.Core.Services.CryptoService.MakeKeyAsync (System.String password, System.String salt, System.Nullable`1[T] kdf, System.Nullable`1[T] kdfIterations) [0x00087] in <6dfd726fecb34ba79c31a035ec98a215>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at Bit.App.Pages.LockPageViewModel.SubmitAsync () [0x0078a] in <0c3398d4c9ce4e56ba576728f942d695>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at Bit.App.Pages.LockPage.<Unlock_Clicked>b__17_1 () [0x00067] in <0c3398d4c9ce4e56ba576728f942d695>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__7_0 (System.Object state) [0x00000] in <8f1a893b5ab6478299d5fb8196347666>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at Android.App.SyncContext+<>c__DisplayClass2_0.<Post>b__0 () [0x00000] in <3b6b09cca6ad40039584e80046fcd050>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in <3b6b09cca6ad40039584e80046fcd050>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00008] in <3b6b09cca6ad40039584e80046fcd050>:0
10-19 00:14:17.606 24415 24415 I MonoDroid:   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.51(intptr,intptr)
10-19 00:14:17.617  4183  4183 I Layer   : id=18180[1] Destroyed InputMethod$_2387#0
10-19 00:14:17.667 24415 24415 D AndroidRuntime: Shutting down VM
10-19 00:14:17.668 24415 24415 E AndroidRuntime: FATAL EXCEPTION: main
10-19 00:14:17.668 24415 24415 E AndroidRuntime: Process: com.x8bit.bitwarden, PID: 24415
10-19 00:14:17.668 24415 24415 E AndroidRuntime: android.runtime.JavaProxyThrowable: System.Exception: PBKDF2 iteration minimum is 5000.
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at Bit.Core.Services.CryptoService.MakeKeyAsync (System.String password, System.String salt, System.Nullable`1[T] kdf, System.Nullable`1[T] kdfIterations) [0x00087] in <6dfd726fecb34ba79c31a035ec98a215>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at Bit.App.Pages.LockPageViewModel.SubmitAsync () [0x0078a] in <0c3398d4c9ce4e56ba576728f942d695>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at Bit.App.Pages.LockPage.<Unlock_Clicked>b__17_1 () [0x00067] in <0c3398d4c9ce4e56ba576728f942d695>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__7_0 (System.Object state) [0x00000] in <8f1a893b5ab6478299d5fb8196347666>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at Android.App.SyncContext+<>c__DisplayClass2_0.<Post>b__0 () [0x00000] in <3b6b09cca6ad40039584e80046fcd050>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in <3b6b09cca6ad40039584e80046fcd050>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00008] in <3b6b09cca6ad40039584e80046fcd050>:0
10-19 00:14:17.668 24415 24415 E AndroidRuntime:   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.51(intptr,intptr)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at mono.java.lang.RunnableImplementor.n_run(Native Method)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at mono.java.lang.RunnableImplementor.run(RunnableImplementor.java:30)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at android.os.Handler.handleCallback(Handler.java:883)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:100)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:237)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:7814)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
10-19 00:14:17.668 24415 24415 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1075)
10-19 00:14:17.688  4716 24623 I DropBoxManagerService: add tag=data_app_crash isTagEnabled=true flags=0x2

[TheRedofJaming]

On the latest raspberry pi version, I had the same issue, but with every client. I updated to latest, which fixed it with each client (Chrome-, Safari-extensions, MacOS App, iOS-App) but the android one. Surprisingly, biometrical (re-)login works just fine.
As a workaround, you might want to use this method for now.

[reydus]

I built from source the original bitwarden mobile repo to see if I could debug it and find a line or something. But the error did not happen in this version. I will compare both the built and the Play Store version.

[windware-ono]

You have to logout and login again than just retyping password which is slightly inconvenient but can avoid the crash for now.

Fingerprint unlocking works fine though.

[BlackDex]

Which version of the android client are you using?

[windware-ono]

I'm using the newest client at the moment which is 2.6.1 (3178).
This happened on both Pixel 4a (Android 11) and Galaxy S10 (Android 10).
I've pulled the bitwardenrs/server:latest image now but it's still happening.

[windware-ono]

This is also happening on macOS (10.15.7).

I'm using Edge 86.0.622.48 with the official Bitwarden extension version 1.46.2 which are both the newest versions at this point.

Whenever the vault gets locked and it used to unlock fine by just typing the password but now I have to logout and login again as it says "Invalid master password", though I'm typing in the right one but it's not crashing anything for macOS.

[BlackDex]

@windware-ono, how did you install bitwarden? Plain docker or docker compose? Did you also restart your reverse proxy after the update.
Can you also please verify via the admin interface that the right version is installed?

I'm using the android version 3226, which is a bit newer and i can't reproduce this at all.

Also, what do you see in your logs? What request is coming in at bitwarden.

[potvinp]

I'm currently having this same issue with the Bitwarden mobile app on iOS 14.0.1. Server and web versions are up-to-date (1.17.0 for server and 2.16.1 for web) according to the /admin/diagnostics page, and the date and time matches as well. Installed via docker-compose. When running the docker pull bitwardenrs/server:latest command, Docker says that the image is up-to-date. The Bitwarden mobile app on my iPhone XS is running version 2.6.1, which appears to be the latest version on the App Store.

When logging in via the mobile app, the following entry shows up in the server's logs:

[2020-10-24 20:22:16.778][rustls::msgs::handshake][WARN] Illegal SNI hostname received [50, 48, 57, 46, 49, 52, 49, 46, 52, 50, 46, 49, 56, 55]

I'm unsure if this is an issue caused by the server or the client, but I can login without issues in Google Chrome with the extension running on MacOS and on Windows.

[windware-ono]

@windware-ono, how did you install bitwarden? Plain docker or docker compose? Did you also restart your reverse proxy after the update.

I installed it via docker-compose.
I haven't changed the reverse proxy's setting but I just restarted it but no change.

Can you also please verify via the admin interface that the right version is installed?

Where do I find the bitwarden_rs version? I saw it says 2.14.0 in the footer, but I assume this is actual Bitwarden's version that's being used.

I'm using the android version 3226, which is a bit newer and i can't reproduce this at all.

I can't see any newer version than 2.6.1 at the Play Store, so I'm at 3178.

Also, what do you see in your logs? What request is coming in at bitwarden.

Say, I have the Android Bitwarden app at the unlocked state, and if I go to Lock Now in the settings, it locks me out and if I type in the password to unlock, it crashes but the server doesn't see any new logs.
If I logout and login again using the password, the server sees new log entries and it succeeds. Like said above, using the fingerprint to unlock after locking works fine but no new logs at the server for this as well.

It's the same for macOS, except the browser extension doesn't have fingerprint unlock feature.

So, it does sound like it's the client's problem when it crashes without contacting the server but I don't have knowledge of the internal working mechanism to be sure.

[Office-Monkey]

I was afflicted by this for the last few days on Android. I was able to workaround it by: updating my server build (it was overdue) AND clearing both cache and data for the application (uninstall/reinstall might also work?). Hope this might help someone else.

[BlackDex]

@reydus were you able to solve this issue using the provided comments and updating your server and maybe by clearing the cache of the mobile application?

[nwallace]

I had the same issue happening on iOS. Turns out I had some bad data other clients handled fine, but the phone didn't. In my case, I had a Login URI whose URI was null.

To find the borked data, I whipped up a Ruby script to help:

$ cat << EOF > /tmp/find_nulls.rb
#! /usr/bin/env ruby

require 'json'

def find_nulls(item, path=[])
  case item
  when Hash
    item.each do |k, v|
      find_nulls(v, path + [k])
    end
  when Array
    item.each_with_index do |v, i|
      find_nulls(v, path + [i])
    end
  when NilClass
    puts path.join(".")
  end
end

find_nulls(JSON.parse(STDIN.read))
EOF

$ chmod +x /tmp/find_nulls.rb
$ bw list items | /tmp/find_nulls.rb

You can scan the output manually to find fields that don't sound like they should be null, or use various other tools to help out. I did this to help me see and ignore the fields that are normally null:

$ bw list items | /tmp/find_nulls.rb | cut -d '.' -f 2- | sort | uniq -c | sort -n

[Starfiresg1]

I had the same issue on both my android devices.
The following procedure fixed it for me:
Updating my docker to the latest version (this alone didn't fix it)
Logging out of the vault on the Android App and logging back in (accessible through the 3 dots in the corner on the unlocking page)
After that I can unlock a locked vault without crash

Seems to me that the crash on unlocking is maybe created by the initial login with an older Bitwarden_rs version, because after the server update the issue still persisted until I logged in fresh.

[kenan435]

Seems to me that the crash on unlocking is maybe created by the initial login with an older Bitwarden_rs version, because after the server update the issue still persisted until I logged in fresh.

But that does not explain why logging in via biometrics works. I'd rather say that it happens while the master phrase is being validated.

[BlackDex]

It is because in the code of the client the master-password entered to unlock is verified at the server side.
But that wasn't available on the older versions of bitwarden_rs. Bio-Unlock bypasses this, because it doesn't have to verify the master-password. Maybe the client caches the 404 result, and just ignores a new request or something?

[daniellandau]

For me it got fixed exactly as @Starfiresg1 described.

[BlackDex]

@nwallace, maybe a bit late. But a Uri as also Uris can definitely be null. What I'm curious about is, if for that same cipher if it at one place had uri or uris filled and not at the other. Or has uris filled but not uri. Do you still remember that?

[BlackDex]

Converting this issue to a discussion.