Access Database Password Recovery

Identify Your File: .mdb or .accdb?

The single most important question in Access recovery is which storage engine wrote the file. Everything else — whether it takes five seconds or five days, whether a free utility handles it or you need a GPU cluster — flows from that one decision.

The Jet engine (.mdb) shipped with Access 95, 97, 2000, 2002 (XP) and 2003. It writes files with the .mdb extension. If you open the file in a hex editor the first bytes will be 00 01 00 00 53 74 61 6E 64 61 72 64 20 4A 65 74 20 44 42 ("Standard Jet DB" in ASCII) or similar. Password recovery is instant and does not depend on password length.

The ACE engine (.accdb) replaced Jet starting with Access 2007. It writes files with the .accdb extension. The header contains Standard ACE DB. Password recovery for these files uses real cryptographic attacks — dictionary and mask on hashcat — and success depends on password strength.

Modern versions of Access (2010, 2013, 2016, 2019, 2021, 365) still default to .accdb but can be configured to save in the legacy .mdb format for backward compatibility. That configuration choice matters more than the version number. A database saved today in .mdb format is still encrypted with the broken Jet cipher, because the file format dictates the cipher, not the Access version.

The Jet .mdb Cipher: Broken By Design

To understand why .mdb passwords fall in milliseconds, it helps to see what Microsoft actually did. The Jet engine stores the database password as a thirteen-byte block starting at offset 0x42 in the file header (Jet 3) or offset 0x42 encrypted by a rolling XOR with an offset-dependent key (Jet 4). Both the XOR key and the exact byte layout are documented in public reverse-engineering work dating back to the late 1990s. The whole scheme is equivalent to typing the password backwards and calling it encryption.

A small Python script can decode it without any brute force:

# Jet 4 XOR key (Access 2000/2002/2003)
XOR_KEY = bytes([0xBE, 0xEC, 0x65, 0x9C, 0xFE, 0x28, 0x2B, 0x8A,
                 0x6C, 0x7B, 0xD3, 0xE4, 0x7C])

with open("database.mdb", "rb") as f:
    f.seek(0x42)
    encrypted = f.read(13)

password = bytes(b ^ k for b, k in zip(encrypted, XOR_KEY))
print("Password:", password.decode("ascii", errors="replace").rstrip("\x00"))

This runs in under a millisecond and works for every Jet 4 .mdb file ever written. For Jet 3 files (Access 95, 97) the key is slightly different but the principle is identical. Free utilities such as the old Elcomsoft Advanced Office Password Recovery, the open-source mdbpwd, or countless online scripts perform the same decoding.

Bottom line. If you have an .mdb file with a forgotten database password, do not brute force it. Do not send it to a GPU recovery service. Run any Jet password tool locally in five seconds and move on. The only reason the file even feels "locked" is because Access itself honors the password flag — the data is decryptable whether Access cooperates or not.

The .accdb Cipher: Real Cryptography

Microsoft used the 2007 rewrite to fix the long-standing Jet weakness. The .accdb format stores the database password as an RC4-encrypted blob with a key derived from the password through SHA-1 and a random sixteen-byte salt. Access 2010 and later upgraded the primitives further to AES-128 with PBKDF2-SHA-1 at 50,000 iterations, and Access 2016 moved the default to AES-128 with PBKDF2-SHA-512 at 100,000 iterations — very close to the modern Office file encryption scheme.

The practical consequence is that an .accdb password cannot be decoded. It must be guessed. Recovery tools generate candidate passwords (from a dictionary, from a mask, or by rule mutations of a base word) and test each one by deriving the key and attempting to decrypt a known header block. A match proves the password.

Hashcat support. As of hashcat 6.x there is partial support for Access .accdb recovery through community-maintained forks. The canonical workflow is:

1. Clone john-the-ripper jumbo to get office2john.py. Although named after Office, it handles Access 2007+ too.
2. Run python3 office2john.py mydb.accdb > hash.txt.
3. For Access 2007 use hashcat mode 9700 (RC4-SHA1) or the dedicated 9800 variant.
4. For Access 2010+ use hashcat mode 9500 (2010) or 9600 (2013+).
5. Feed a wordlist such as rockyou-1-60.txt with the T0XlC rule set for a first-pass dictionary attack.

Success rates for .accdb passwords in our real-world queue mirror the Office queue: roughly 55-65% recovered when the password was a dictionary word, a name, a date, a phone number or a simple pattern — and near zero when it was a random 12+ character string. Users who picked passwords like "admin2019" or "Reports!" are the success stories; users who picked random generated strings from a password manager are the sad ones.

Workgroup (.mdw) Security — The Other "Password"

For a long time Microsoft sold Access as enterprise-ready by bundling a user permission model that looked superficially like Windows NT. Administrators created users inside a System.mdw file, granted read/write permissions per table, and shipped the .mdw along with the .mdb. When you open such a database Access prompts for a username and password that have nothing to do with the .mdb database-open password. The credentials are verified against the workgroup file.

The workgroup system is even weaker than the Jet database cipher. The entire permission check is client-side inside msaccess.exe; strip the .mdw reference from the shortcut and you see every table. There is a specific Microsoft Knowledge Base article (KB 277814) that acknowledges the weakness. Since Access 2007, workgroup security is gone for .accdb and lingers only when editing legacy .mdb files.

If you hit a "login" dialog when opening a database, rather than a simple password prompt, you are dealing with workgroup security. Recovery means decrypting the SID entries in the .mdw, which is different from decrypting the .mdb. Free tools such as "AccessPR" or "MDW Viewer" handle it.

VBA Project Password — A Third Flavour

Access, like Excel and Word, supports custom VBA code behind forms, reports and macros. That code can be locked with a VBA project password in the VBE under Tools → Properties → Protection. This is a completely separate password from the database-open password and the workgroup password.

Good news: the VBA project password is not real encryption. It is a flag byte stored in the project's DPB field. Flip the flag and the password is bypassed. Our dedicated guide Excel VBA project password recovery walks through the hex-edit method; the exact same technique works for Access .accdb and .mdb containing VBA projects.

Step-by-Step: Recover an .mdb Password Locally

1. Make a backup. Copy the .mdb file to a safe location before touching it. Always.
2. Open in a hex editor. Free tools like HxD on Windows or xxd on Linux work fine.
3. Seek to offset 0x42. The next thirteen bytes are the encrypted password block.
4. XOR with the Jet key. For Jet 3 (.mdb from Access 95/97) use the Jet 3 key; for Jet 4 (Access 2000/02/03) use the key shown above.
5. Interpret the result as Latin-1 text. Password strings are stored null-padded.

If hex is not your style, the dated but still-working Advanced Office Password Recovery trial, or the free accdb-password-reader on GitHub, produce the same output with one click. Either path ends in seconds.

Step-by-Step: Attack an .accdb Password on a GPU

1. Extract the hash. python3 office2john.py confidential.accdb. Save the output line to hash.txt.
2. Choose your hashcat mode. Run hashcat --example-hashes | grep -i access to confirm the mode for your Access version.
3. Run a dictionary. hashcat -m 9600 -a 0 hash.txt rockyou.txt -r rules/best64.rule. A 14M-word dictionary with best64 rules finishes in under an hour on a single RTX GPU for the Office2013 mode.
4. Escalate to mask. If the dictionary fails, try -a 3 ?l?l?l?l?l?d?d?d?d for 10-character patterns.
5. If you do not own a GPU, upload your file to our recovery service. We run a free check against 140M+ common passwords before quoting anything.

Common Misunderstandings

Recovery Chances by Access Version

Recovery rates in the right-hand column reflect our actual queue results on passwords that turned out to be something a human being chose. Truly random passwords from a password manager are not recoverable at any scale.

Frequently Asked Questions