Speed Analysis

Outlook PST Password Crack Speed — What Actually Matters

Outlook PST (Personal Storage Table) files behave differently from every other Office format: the message store is obfuscated with two keyless ciphers, and the password is not an encryption key at all but a CRC-32 checksum stored alongside the data. That changes the whole recovery picture — the check is cheap to test, collision-prone, and cracked with John the Ripper's PST format rather than with hashcat. This article explains the real PST password mechanism, what it means for crack speed, and how to set realistic expectations for recovery.

PST encryption — a unique scheme

Unlike Office documents (.docx, .xlsx), which use the ECMA-376 encryption families, PST files use a completely separate scheme — and it is not encryption in the password-protected sense at all. The message store is obfuscated with two keyless ciphers (Permute and Cyclic) that Microsoft itself describes as data obfuscation; the password is a separate, superficial check, stored as a CRC-32 checksum of the password string. It is not an encryption key, and no key derivation exists.

The PST header records a per-file encryption type (bCryptMethod): 0x00 (none), 0x01 (Permute, shown as 'compressible') and 0x02 (Cyclic, shown as 'high'), plus 0x10 for Windows Information Protection-encrypted files. The value is chosen when the file is created rather than fixed by Outlook version, and compressible (0x01) is the common default in modern PSTs. There is no 0x03.

The password check is cracked with John the Ripper rather than hashcat: hashcat has no PST mode at all, and there is no mode number to cite for PST. John's PST format stores the value as '$pst

#x27; followed by 8 hex digits — the 32-bit CRC of the password — and verification is a CRC comparison, not a decryption of the file header. Per-candidate cost is very low: a single CRC-32 pass, with no iterations, which is why this is a CPU-cheap check rather than a GPU job.

PST vs Office document encryption

The PST password is a CRC-32 checksum, not a KDF output — no PBKDF2 and no SHA-512 iteration is involved. That makes it far cheaper to test per candidate than an Office document password (modes 9400 and 9500 cost 50,000 and 100,000 SHA-1 iterations per candidate, mode 9600 costs 100,000 SHA-512 iterations), but the candidate space a human password lives in is what decides the outcome. Because the stored value is only 32 bits, the check is also collision-prone, which is why John's PST format is flagged as not exact.

How fast can a PST password actually be tested?

There is no GPU-generation benchmark table to publish for PST, because no hashcat mode implements the check. What exists is a single CRC-32 pass with no iterations, and John the Ripper's PST format runs in the tens of millions of candidates per second on one CPU core — orders of magnitude beyond what any Office AES format manages on a GPU.

That has a practical consequence for how recovery is approached. Because the stored value is only 32 bits wide, the space of possible verifier values is roughly 4.29 billion regardless of how long the original password was, so a collision is what the search is really looking for. A long random password and a short one collapse into the same verifier space.

The honest answer to 'how fast' is therefore: fast enough that GPU hardware is not the limiting factor. The limiting factor is whether the file can be read to extract the checksum in the first place — a format and tooling question, not a compute question.

Password strength still decides the outcome

The timelines that matter follow from the password, not from GPU throughput. For a password a human chose, a rules-heavy dictionary attack is the first step and usually the last one needed: it finds dictionary words, names and leetspeak variants quickly, which covers the large majority of real-world PST passwords.

Where the password was long and genuinely random, the checksum's collision space is the practical route rather than exhaustive search of the original keyspace. Only about 4.29 billion verifier values are possible, so a candidate that reproduces the stored CRC is accepted whether or not it is the string the user originally typed — which is why a 'recovered' PST password should always be verified against the file before it is relied on.

PST vs OST — encryption differences

OST (Offline Storage Table) files carry no password at all — Microsoft provides no way to set one on an .ost file, because it is a profile-bound cache rather than a standalone document. Access is governed by the MAPI profile and the Exchange account. The only thing OST shares with PST is the block obfuscation (Permute/Cyclic), not the password checksum.

OST recovery is therefore bound by Exchange account recovery rather than password cracking. If the email account is accessible via Exchange webmail (OWA) or the Exchange ActiveSync connection, the data can be re-downloaded as a new PST, bypassing the OST entirely.

Standalone PST files (created by backup, export, or archive) have an independent password set by the user. The PST is not tied to any server or account — but the password is a gate enforced by the Outlook client only, not a key protecting the data: because it is not used to encrypt the message store, tools such as libpff (pffexport) and libpst (readpst) can read an encrypted PST without it. Try extraction before cracking.

Practical advice for PST recovery

Before committing to PST password recovery: verify the PST is not backed up elsewhere (old computer, cloud export, Exchange server). Check whether the password might be stored in a browser, password manager, or written down somewhere. The most efficient recovery is finding the password, not cracking it.

If cracking is necessary: a rules-heavy dictionary attack against the CRC-32 verifier with John the Ripper (--format=pst) is the first step — it finds human-chosen passwords quickly. A mask attack with character-class constraints (you know it has digits but no symbols, etc.) is the second step. Exhaustive search of a long random password's original keyspace is the last resort, and it is usually unnecessary given the verifier is only 32 bits wide.

Professional recovery services provide a free analysis that tests common passwords and dictionary candidates before committing to a paid plan. This pre-check often succeeds for common password patterns and avoids unnecessary expense.

PST password cracking flow

1
Read the stored password checksum
Open the PST's message store (libpff's pffinfo/pffexport, or another OLE-aware tool) and read the stored CRC-32 value. There is no hashcat extraction script for PST and no hashcat mode to feed it to — the target tool is John the Ripper.
2
Check the encryption type
The header records bCryptMethod: 0x00 (none), 0x01 (Permute/compressible), 0x02 (Cyclic/high) or 0x10 (WIP-encrypted). This only affects how the data blocks are obfuscated; it does not change the password check.
3
Run a dictionary + rules attack
Feed the $pst$ + 8-hex-digit value to John the Ripper with --format=pst, starting with a rules-heavy wordlist pass. The check is a single CRC-32 pass per candidate, so raw candidate volume is not the bottleneck.
4
Escalate to a mask attack if needed
Apply character-class constraints based on what you remember. Again, candidate counts are cheap here — one CRC-32 per candidate.
5
Assess feasibility before escalating
For a long random password, remember the verifier is only 32 bits: the practical route is a colliding candidate rather than exhausting the original keyspace. Check alternative paths first (Exchange export, backup) — and remember an encrypted PST can often be read without the password at all.

Frequently Asked Questions

Is PST encryption the same as Office document encryption?

No. The PST password is a CRC-32 checksum of the password string, and the message store is obfuscated with two keyless ciphers — nothing like an Office document, which uses the ECMA-376 families (SHA-1 iteration in hashcat modes 9400/9500, SHA-512 iteration in mode 9600 for the Office 2013+ AES generation). Hashcat has no PST mode.

How fast can I crack a PST password?

Fast — the check is a single CRC-32 pass with no iterations, so it runs in the tens of millions of candidates per second on one CPU core and does not need a GPU at all. And because the stored value is only 32 bits, the verifier space is roughly 4.29 billion values regardless of how long the original password was.

Do OST files use the same encryption?

No — OST files cannot be password-protected at all. They share only the block obfuscation (Permute/Cyclic) with PST; access is governed by the MAPI profile and the Exchange account, so account-based recovery is the only route.

What if I only remember part of the password?

Mask attacks with known characters (e.g., ?l?l?l?d?d?d?l?l for 'abc123xy') narrow the search space dramatically. Even partial recall like 'starts with J' helps.

Can I recover a PST password without cracking it?

Often yes — try extraction first. Because the password is not used as a key to the store's ciphers, tools such as libpff (pffexport) and libpst (readpst) can read an encrypted PST without it. If the data still lives on an Exchange account, re-export as a new PST instead.

What makes PST password testing faster than Office document cracking?

The check itself: a single CRC-32 pass per candidate versus 100,000 SHA-512 iterations per candidate for mode 9600, which runs at roughly 25-30 kH/s on a 4090-class GPU. PST has no hashcat mode, and that comparison is exactly why it does not need one.

Need Office password recovery?

Run a free analysis — encryption type detected automatically, fast techniques tried first, pay only on success.

Run Free Analysis