If you're locked out of an old Blockchain.info or Blockchain.com wallet because you've forgotten the password, the situation is usually better than it feels. A forgotten password is not a lost wallet. As long as you still have the encrypted backup file, the keys are inside it, and the job is to find the password that unlocks them. That job is a targeted brute force, and this is how I actually do it, including what determines whether it takes an hour or is hopeless.
Before anything else, two safety rules. Do not paste your backup or your password into a "wallet decrypt" website, and do not hand either to anyone who contacted you first. Uploading an encrypted wallet.aes.json to a stranger is how a recoverable wallet becomes a stolen one. If you're deciding who to trust, read how to tell a legitimate recovery service from a scam first. If your backup won't open at all rather than won't accept a password, start with Blockchain.com backup file won't decrypt, which triages the "decrypt failed" case specifically.
The backup format: v1, v2, and v3
Locked out of a wallet like this one?
I repair hardware wallets, crack forgotten passwords, and rebuild broken seed phrases — on my own bench in Denver.
Blockchain's "My Wallet" web wallet stores everything as a single AES-encrypted JSON payload, saved to disk as wallet.aes.json. Your password is stretched with PBKDF2-SHA1 and the result is used as the AES key. Nothing inside is readable until the password decrypts it, which is exactly why brute forcing works: a candidate password either produces valid wallet JSON or it doesn't, and the tool can check millions of candidates against that test.
The format has three versions, and knowing which you have matters because it sets the difficulty:
- v1 is the oldest layout, from the earliest Blockchain.info wallets. It used a lower PBKDF2 iteration count and a slightly different structure. A decoder that assumes a newer version will fail to open a perfectly good v1 file, so "it won't decrypt in the tool I tried" is often just a version mismatch.
- v2 and v3 are the modern layouts. They default to 5,000 PBKDF2-SHA1 iterations, which you'll see reported when a recovery tool opens the file (look for the line
Wallet difficulty: 5,000 PBKDF2-SHA1 iterations).
The iteration count is the single number that governs how fast you can test passwords. Every candidate password has to run through those 5,000 PBKDF2 rounds before the AES check, so 5,000 iterations means each guess is 5,000 hash operations. That's what makes a GPU essential, and it's why a wallet's version, not the password's length alone, sets the pace.
Why a GPU, not a CPU
Blockchain.info wallets should be run on a graphics card, because it's over 10x faster than a CPU for this workload. I use a special mining driver, because Nvidia limits the hash rate on its newer cards and drivers, and that limit can also throttle brute forcing. The hardware to do this costs a few thousand dollars, but neither the hardware nor the software is exotic. The tricky part is almost never the raw speed.
What actually determines your odds
This is the part people get wrong. They assume recovery is a hardware problem, a matter of buying a faster card. It almost never is. It's a search-space problem.
The number of possible passwords grows exponentially with length and character variety. A truly random 12-character password with mixed case, digits, and symbols is beyond any hardware, and always will be. What makes real wallets recoverable is that almost nobody uses a truly random password from memory. They use something with structure: a base word or phrase, a capital at the front, a number or a year at the end, a symbol they favor, small variations on a password they used elsewhere.
The whole craft is turning what you remember into a token list: the fragments, the words you tend to use, the number ranges, the substitutions. The recovery tool then combines and mutates those tokens. Get the token list right and a search that would take millennia by brute force finishes in hours or days. Get it wrong and even infinite hardware won't help, because the correct password was never in the set being tested.
So the factors that actually decide the outcome, in order:
- How much you remember. Fragments, length, "it was probably one of these three base words," an approximate year. This is worth more than any GPU. If you remember nothing at all and the password was long and random, be honest with yourself: that one may not be recoverable.
- The wallet version and iteration count, which set how many candidates per second are possible.
- Hardware, which matters least, and only scales what's already a well-defined search.
That ordering is why the intake questions I ask are all about what you remember, not about your equipment.
A real run
Here's the actual command from a recent recovery. This particular search was a batch of about 300 million passwords, but it took over a billion total candidates to crack because my process expands through ever-larger token sets until one hits. The whole thing ran about a week on an Nvidia RTX 3060.
python btcrecover.py --tokenlist tokens5.txt --wallet wallet.aes.json \
--enable-opencl --dsw --max-eta 500 --no-dupchecks \
--typos 1 --typos-delete --typos-closecase --typos-repeat \
--typos-swap --typos-insert %p
The --typos flags are the mutation engine: they let the tool try each token with a character deleted, a case flipped, a letter repeated, two letters swapped, or a character inserted. That's how "the password I remember, but slightly wrong" gets found. The console output looks like this:
Wallet Type: btcrpass.WalletBlockchain
Wallet difficulty: 5,000 PBKDF2-SHA1 iterations
Counting passwords ...
Done
2022-01-11 08:40:37 : Using 2 worker threads
275224793 of 296110434 [######################----] 10:53:17, ETA: 0:49:34
Password found: '#######'
That Wallet difficulty: 5,000 PBKDF2-SHA1 iterations line is the tool confirming a modern v2/v3 backup. The progress bar is candidates tested against the file; the moment one produces valid wallet JSON, it stops and prints the password.

The second-password trap
One more thing that trips people up. Blockchain wallets had an optional second password that separately encrypts the private keys inside the already-decrypted wallet. If you can log in and see a balance but can't spend, the wallet opened and the keys did not. That's a second, independent brute-force problem, and it's covered in the decrypt-failed guide. If it applies to you, write down everything you remember about the second password separately from the main one.
Realistic timelines
- You remember the password roughly (a base word plus the usual mutations): often hours to a couple of days.
- You remember fragments and a rough length: days to a couple of weeks, depending on how large the token space gets.
- You remember essentially nothing and it was long and random: this is where honesty matters. It may not be recoverable at any timeline, and a legitimate service will tell you that rather than bill you to run a search that can't finish.
If you'd rather not build the token list and run the hardware yourself, that's the service: Blockchain.com wallet recovery by David Veksler, with published pricing, a free assessment, and no fee until your crypto is back. In the first message, describe what you have and what you remember, not your actual password or your backup file. Get your free assessment →
