[harrygeez]

There are a few convenient scapegoats here but ultimately in this case it is not biometric unlock that enabled this but rather characteristic of the Active Directory's design (I'm not sure I will call it a weakness).

For Android and iOS if you forget your PIN code I believe you are screwed, as in no one can decrypt your device for you.

[RedTeamPT]

Actually it is not just an issue with AD design, but the AD design only makes it slightly worse. The underlying issue is that biometrics are not required to retrieve the biometric key from DPAPI and instead of authenticating with Windows Hello, any program could just simply ask DPAPI for the key.

[magicalhippo]

My understanding from a quick reading is that Bitwarden essentially used Windows Hello to ask "is the user there" and if so, asked DAPI to give Bitwarden the secret vault credentials which it happily did because that's its job.

The problem with this was that the vault credentials in DAPI was not safe from other programs running as the user, nor from domain admins which could use the recovery key stored on the AD server (which they did in their attack after gaining admin access).

The solution was to use Windows Hello the way it was meant. That is, to store an asymmetric key pair, where the private key is hidden and protected by the biometrics or hardware security key, and use that to encrypt the secret vault credentials before storing them in DAPI.

[lxgr]

Have you looked into how (whether?) Windows Hello actually checks which app is asking it to perform a private key operation?

On Android, this is tied to the app UID, and on iOS/macOS it's tied (I believe) to the developer team identifier. Hopefully there's a similar mechanism on Windows...?