Bitwarden Heist – How to break into password vaults without using passwords

Original Article ↗ Hacker News Discussion ↗

Security researchers describe a now-fixed flaw in Bitwarden’s Windows client that let any process running as the user extract the key to decrypt a biometrically unlocked vault via DPAPI, without prompting for a password or biometrics. Commenters note that the attack required local access and was most potent in compromised Active Directory environments, but use it to highlight broader weaknesses in Windows’ app isolation, legacy protocols, and filesystem conventions like `%AppData%`. The thread broadens into a debate over the real-world risks and benefits of password managers, given their “single point of failure” nature versus the widespread problem of password reuse.

Scope of the Bitwarden Issue

  • Vulnerability is Windows-only, tied to Bitwarden’s biometric unlock on Windows.
  • Original flaw: any process running as the same low-privileged user could read a JSON file and ask DPAPI for the “biometric key” to decrypt the vault, no Windows Hello prompt, no extra privileges.
  • In some pentest scenarios, domain admin access was used to pull DPAPI backup keys from Active Directory and decrypt vaults offline; in others, only local user access was needed.
  • Bitwarden reportedly fixed the design in v2023.4.0 and changed defaults so the master password must be entered at least once on startup when using Windows Hello.

Debate: Serious Vulnerability or Overhyped?

  • Some see the blog and title as clickbait, noting:
    • Requires local access (and sometimes domain compromise), which is often “game over” anyway.
    • Attack is specialized and already patched.
  • Others argue it’s still noteworthy because:
    • It avoids noisier techniques (keyloggers, memory dumping) and may bypass some endpoint defenses.
    • Local access may come from compromised coworkers or untrusted software, not just obvious “physical attack.”

Biometrics, DPAPI, and Platform Differences

  • Critique: Bitwarden initially used Windows Hello just to confirm “user is present,” then stored a symmetric vault key in DPAPI, which any same-user process (or domain admin via AD backup keys) could retrieve.
  • Suggested correct pattern: Windows Hello should hold an asymmetric key; its private key (guarded by biometrics) encrypts the vault key before it goes into DPAPI.
  • Android/iOS are seen as easier to secure due to app sandboxing and keychain models; no similar issue is known there from the thread.
  • macOS/App Store version behavior around biometrics and Keychain is mentioned but details remain unclear.

Windows AppData, Sandboxing, and Security Model

  • Heavy criticism of %AppData% and the general “any process as the user can read any of the user’s app data” model.
  • Others respond this is by design: AppData was never meant to be a secure store; if you can run code as a user, you can exfiltrate their secrets.
  • Broad discussion of:
    • Lack of strong default app isolation on Windows vs mobile OSes.
    • Attempts like UWP, AppContainer, MSIX, and upcoming filesystem-based isolation, hampered by backward compatibility and developer resistance.

Password Managers as Single Point of Failure

  • Some distrust password vaults as obvious SPOFs holding “all your secrets.”
  • Many counter that:
    • Without them, users reuse weak passwords, which is worse in practice.
    • A vault plus strong master password and 2FA/MFA is a good compromise.
    • Compromise of an already-unlocked vault is bad, but local malware could often steal active sessions or keylog keystrokes anyway.
  • Mitigations discussed:
    • Keeping a few critical passwords memorized and out of the vault.
    • Using hardware tokens (e.g., security keys) and separate 2FA storage.