Warning: Blockchain.com 2FA Disabled Without Permission + Reuse of 2FA Secret —

[Quantum_Resolve7987V]

The 2FA secret is never reset automatically by Blockchain.com.

That’s not really the issue here. Nobody said the 2FA secret “resets automatically.” The point is that Blockchain.com doesn’t provide any proper recovery mechanism (like backup codes), and instead their “solution” is customer support disabling 2FA for you — which completely undermines the security model.

If you think about it, that creates a bigger attack surface than the 2FA secret itself: a social engineering vector. Someone doesn’t need to compromise the authenticator app, they just need to convince support to disable it. That’s exactly the kind of flaw worth pointing out, because it means the 2FA is only as strong as the customer service agent on the other end of the chat.

This isn’t about whether funds should be moved (obviously they should, because Blockchain.com is custodial at its core). It’s about analyzing design flaws so others understand the risks — and this particular one is a big deal.

[Quantum_Resolve7987V]

No argue about discussing the quality of any service. For your knowledge, there is already a full child board dedicated for web-wallets service discussion, where you can share your experience based opinions. My reply was because you posted here in this board with a hard work full analysis that fit to that board. Otherwise, i would like to thank dedicating time to warn community and want to help.
You can move this topic to service discussion sub-board: Web Wallets

I appreciate the suggestion to move this to the Web Wallets section—I’ll do that so it reaches the right audience. The 2FA flaws alone are concerning, but the bigger issue is that Blockchain.com’s support disabled 2FA on two of my accounts without proper verification. Even worse, their system allowed unauthorized login attempts to be triggered via email. These aren’t just hypothetical risks; they’re active failures that put users’ funds in danger. The community needs to know.

[nc50lc]

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.

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.

You get it.
It seems like the main purpose of it is to set a convincing "non-custodial" claim (better term: "self-custodial") rather than security purposes.
Still needs the password though if it's on a different machine/device.

This is why most people do not recommend their web wallet aside from their historical mess-up in the past and current issues in the present.

That theory is disturbingly plausible.  
-snip-
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.

It still needs some investigation though.
But it's definitely NOT your password or anything that can't get into the wallet's setting page while 2FA is enabled.