Cracking password manager vaults: KeePass, 1Password, Bitwarden, LastPass

A password manager vault is designed around one assumption: the master password is the only thing standing between an attacker and everything inside it. That is exactly why KeePass, 1Password, Bitwarden and LastPass all run the master password through a deliberately slow key-derivation step before it ever unlocks anything — and why cracking one, when you have lawful access to the file, looks a lot more like attacking bcrypt than attacking raw MD5.

Extract the hash first

None of these vault formats are handed to hashcat as-is. Each has a dedicated John the Ripper extractor that pulls the key-derivation parameters and a verification value out of the vault file:

keepass2john vault.kdbx > keepass.hash
python3 1password2john.py vault.opvault > 1password.hash
python3 bitwarden2john.py data.json > bitwarden.hash
python3 lastpass2john.py export.json > lastpass.hash

Each extractor prints a single line starting with a format-specific prefix — $keepass$, $cloudkeychain$, $bitwarden$, or a bare hash:iterations:email for LastPass. That prefix is the identification step, the same way spotting a $zip2$ or $RAR3$ prefix tells you which archive hash you're looking at. hashcat accepts the extracted line directly.

Picking the mode

Get the mode wrong and hashcat either rejects the line outright with a length or token-count error, or silently runs against the wrong algorithm and never matches. When in doubt, the prefix on the extracted line is the ground truth, not the file extension.

1Password has three generations, not one

This is where most people get stuck. 1Password changed its underlying vault format twice: Agile Keychain (mode 6600, deprecated since 2015), Cloud Keychain / OPVault (mode 8200, PBKDF2-HMAC-SHA512), and the current 1Password 8 app, which hashcat supports separately as mode 31800. Running 1password2john.py against the wrong export, or against a 1Password 8 vault expecting an OPVault-style hash, produces a line hashcat won't parse. Check which app version produced the export before picking a mode.

KeePass's Argon2 wrinkle

KeePass 2.35 and later let you choose Argon2 instead of the classic AES key-transform as the master-key KDF. Mode 13400 was built around the AES/Twofish transform; if keepass2john reports an Argon2-based KDF in the parameters it extracts, check your hashcat version's --example-hashes output before assuming 13400 will match — support for newer KeePass KDF variants has lagged behind the AES case historically.

Why rockyou alone won't cut it

Every format in this table deliberately runs tens to hundreds of thousands of PBKDF2 rounds (or KeePass's equivalent) per guess. That is the same design goal as bcrypt's cost factor: turn a GPU's billions-per-second advantage into a few thousand guesses per second at most. Bitwarden in particular embeds its iteration count directly in the extracted hash, so you can read off exactly how expensive each guess is before you start.

hashcat -m 23400 -a 0 bitwarden.hash targeted.txt -r rules/best64.rule

At that throughput, a generic wordlist-plus-rules run against a strong master password is a multi-week job. Bring a short, high-signal list instead — reused passwords from breach corpora tied to the target, name/date/pet-style patterns, variations on anything you already know about them — the same targeting discipline laid out in wordlists and rules that actually work.

What defenders should actually do

Use a long, unique master password — length matters far more than complexity against a PBKDF2-style KDF, because the iteration count already neutralizes raw guessing speed. Turn on two-factor unlock where the app supports it (1Password's Secret Key, Bitwarden's 2FA), since that adds an input an attacker can't derive from the vault file alone. And if you administer a team's vaults, keep export files and backups out of anywhere a compromised endpoint or cloud share can reach — the key-derivation step only has to run once an attacker already has the file.