Description
There didn't seem to be a category for this on the bug bounty website, so it can go here... It is a critical bug in the blockchain.com wallet which prevents users who have the correct passwords from accessing their funds. Basically some older wallet files (2014 era) are not opened correctly. (It looks like these might have been correctly handled in older versions of the wallet)
The wallets that have this issue store the base58 encoded hex private key, but left off any leading zeroes from the hex representation of this key. What this means is that when the base58 encoded private key is converted back to hex, the leading zeros are absent, resulting in an error that the private key is invalid. (And if the base58 conversion is done without checking length, results in a private key that doesn't correspond to the wallet address). All error messages for which assume that the password is incorrect... The main issue is that for these older wallets, some of the private keys (those where the base58 private key doesn't start with zeros) are represented and load correctly.
This encoding of the wallet private keys is consistent from samples of the same wallet file that I have which date from May 2014 through until today. (So the encoding of this private key was also preserved through the user enabling second password, the HD wallet platform upgrade, etc) The wallet in question was created in April 2014 and did successfully send outbound transactions through to July 2015...
I have actually updated BTCRecover to correctly dump these older wallets and produce the expected private keys here: ***/3rdIteration/btcrecover
Expected Behavior
*When provided with the correct password (and/or second password) the wallet would successfully open. (This bug meant that the wallet actually wouldn't even open to view balances, even when given the correct second password)
*When importing the wallet (Using login . blockchain . com/wallet/import-wallet) with the correct password (and/or second password) all addresses from that wallet file would be correctly imported. (Not just some of the addresses, which is what happened in this instance)
Reproduction Steps
I can't share the client's wallet without breaching their privacy, but the issue in their wallet file is easy to reproduce through manually crafting a wallet file... (They might be happy to share it privately with your engineers)
Manually create a test wallet with a private key where there are leading zeros.
For example:
00bf0896da0e675e4778eeb71a3d6bc5a2730fec0334c81267c80cc82c4dc6c9
would need to be base58 encoded as: 13uxAJdzrNmV6auvRFPFotaMw3zjMgoyDTQBiZAKCi1E
Whereas these 2014 wallets like the one in question would have encoded it as:
3uxAJdzrNmV6auvRFPFotaMw3zjMgoyDTQBiZAKCi1E
When attempting to decode this base58 encoded private key, it would end up as the incorrect length and not be correctly imported.
Essentially, some older tools do handle this correctly and this comes down to how they handle the base58 -> hex conversion. (Though the current official tools do not, nor do they offer useful or accurate error messages) I haven't spent the time to do through where exactly this would have stopped working but it is likely an issue for multiple users...
Screenshots/Logs
If you have the javascript log open when importing one of these older wallet files you get:
import-export.js:311 Result not 32 bytes in length
import-export.js:337 No Private Keys Imported. Unknown Format Incorrect Password
wallet.js:919 No Private Keys Imported. Unknown Format Incorrect Password
Additional Information
This error report is based on a recovery that I did for a blockchain user who has apparently been attempting to get support through the official channels since 2017... (Without success)
A wallet like this should really be included in the set of test wallets against which releases are tested...
