Blockchain.info Two-Factor Authentication Lockout: Correct Credentials Rejected
IndeterminateCustodial platform became inaccessible — whether funds were recovered is not documented.
On April 21, 2013, Narydu, operator of bitcoinargentina.org, lost access to a Blockchain.info hosted wallet despite possessing both the correct primary password and valid Google Authenticator one-time password. The wallet had been accessible via iPhone app and web interface until the previous day. When Narydu attempted login on April 21, the authentication system rejected both credentials with an error, though the iPhone app still displayed the account balance—a discrepancy that suggested a server-side issue rather than incorrect credentials.
Narydu systematically tested suspected causes: verified capslock was off, confirmed system time synchronization with Blockchain.info servers (known to cause 2FA failures), entered the password character-by-character, and attempted login from a clean Windows 8 PC. All tests failed.
Blockchain.info's security architecture created a critical constraint: accounts with two-factor authentication enabled were locked for 2 hours after 4 failed login attempts. Narydu approached this threshold and feared permanent lockout. The documented support recovery path—requesting a two-factor authentication reset from Blockchain.info—had taken at least 8 days with no resolution in a similar case reported by community member internationalaw.
Attempts to bypass the web interface via Blockchain.info's API also failed; the API rejected requests when two-factor authentication was enabled. This eliminated the primary technical workaround. The user's BTC balance remained visible in the app but inaccessible for withdrawal or transfer. No resolution appears in the thread record, leaving the final outcome unknown.
| Stress condition | Vendor lockout |
| Custody system | Exchange custody |
| Outcome | Indeterminate |
| Documentation | Partial |
| Year observed | 2013 |
| Country | Argentina |
Why custodial Bitcoin fails differently than self-custody
Exchange custody transfers the custody problem from the holder to the institution. The holder no longer needs to manage seed phrases, maintain hardware, or understand cryptographic concepts. They need only to maintain their account. This simplicity has a cost: the holder no longer controls the private keys. Access depends entirely on the continued operational, financial, and regulatory health of the exchange.
Cases in this archive show that exchange failures cluster around specific event types: bankruptcy and insolvency, regulatory seizure, geographic sanctions, and account-level access failures (lost 2FA, forgotten email credentials). Each event type has a different recovery path and a different timeline. Bankruptcy proceedings typically take 6-24 months and produce partial recovery. Regulatory seizure timelines depend on legal process. Account access failures may be resolvable through platform support or may not.
The distinguishing feature of vendor lockout cases is that recovery — when it occurs — happens through processes the holder did not design and cannot control. They become claimants in a process rather than holders of an asset.
The primary protection against vendor lockout is not using a vendor for custody beyond what is needed operationally. Holdings intended to be stored long-term are most exposed to institutional risk. Exchange custody is well-suited for active trading and conversion; it is poorly suited for long-term storage of significant value. Moving Bitcoin off exchange into self-custody eliminates platform dependency at the cost of taking on personal custody responsibility.
Translate