Quote from: USERNAME

If they're following what they claim: only your encrypted "wallet.aes.json" file is saved in their server.
Decryption is done client-side in your browser so as the seed contained in the wallet once decrypted.
Here's the reference to it: https://bitcointalk.org/index.php?topic=40264.0 [official Blockchain(dot)info topic, unknown to some]

With that, the attacker still needs your password to decrypt the wallet.

As for the source code, only the front-end of the wallet is available: github.com/blockchain/blockchain-wallet-v4-frontend/tree/development/packages
So verifying it may not be possible.

That might be what they claim in theory — but my personal experience with the UI says otherwise.
Once you’re logged in (with the password already entered), there’s literally a “click to reveal” button for the seed phrase. No additional password prompt, no 2FA challenge — nothing.
So if someone gains access to the account at any point (either through direct compromise or a support blunder), they can grab the seed immediately without knowing or guessing the password again.

That’s the real issue — even if the underlying storage is encrypted on their servers, the way it’s implemented effectively means your seed is “hot” and ready to hand over to anyone in your session. It defeats the purpose of client-side encryption if the server happily feeds the encrypted blob to anyone logged in and the client auto-decrypts it on demand.

Quote

With that incompetence, there is a high chance that the one who requested the 2FA removal was using a similar Email address that the customer support mistakenly thought it's yours.
Because if you used the linked email address to contact their customer support, they'll lower their verification requirements for such requests.
Or if he knows something about your wallet like its first created date (based from your first transaction) and some IP address that you've used, he might be able to use that to bypass the linked-email address requirement.

That theory is disturbingly plausible.
Given the near-zero response window between the “new IP” email and the “2FA removal approved” email, it feels less like a brute-force hack and more like a support-side action (whether mistaken identity or deliberately lax verification).
If their process allowed someone to remove 2FA without my approval and without any proper waiting period, then the entire “security” model falls apart.

My opinion: Blockchain.com’s support processes are the biggest vulnerability here — not my password strength, not phishing, not some exotic exploit. Once you can social-engineer their support, the rest of their “layers of security” are just decoration.